The file is currently in a read-only state (file may be in use...

[doug shaffer]

Hello -

 

VW 2018 and VW 2019, Mac OSX

 

I found a few similar topics on this subject but the solutions they offer don't fix my problem.  In the past week or so, using both VW 2018 and VW2019, when opening many Vectorworks I get this error message about 50% of the time.

 

 

I have confirmed that no one else in the office has the file open and that permissions on the server are set properly.  Because the problem seems to occur intermittently, I'm having trouble zeroing in on a solution.  

 

A few things I've tried that didn't work:

-  changed name of file

-  "save as" under a different name

-  erased hidden files that were in the same file as the problem files

-  tried opening in VW2018

-  tried opening same file in VW2019

 

Any thoughts about what may be going on?

 

Thanks -

 

Doug

[Jim Smith]

Is this over a server? I have a colleague who inadvertently worked on a file on one computer that has Landmark installed, & saved it back to the server. He was then getting this error message when opening the file on another machine that only has Architect installed. His fix was to open consistently on the Landmark enabled machine. Perhaps there is another fix, but I'm not sure what that might be.

[doug shaffer]

Thanks, Jim -

 

It is over a server and I suspect that has something to do with my problem.  We only have Architect licenses in our office, so it's not related to a conflict with Landmark.  Thanks for the suggestion, though!

 

Doug

[Jim Smith]

Yeah I think there may be an issue with some files over a server. 

[jonathanmonitor]

Having the same problem in our office, would be good to get a solution

 

Setup:

Vectorworks 2016 Version:21.0.1 (283922)

Windows Server 2012R2 Standard x64 Edition

SMB protocol for access to shares.

[doug shaffer]

I'm pretty sure this won't help your situation, but we solved this by installing the latest MacOS (Mojave) on the affected machine and on the server.  No problem since. 

 

Our setup is:

VW Architect 2018 and VW Architect 2019 (latest SP versions of both)

Mac OSX Mojave - latest update

Server is same as above

[Noface]

I'm in a similar situation and have a windows server 2016 serving my data at the moment. 

I get the read only error from Windows Samba shares, windows nfs share, and I'm about to try a Linux nfs share to test these files.

 

With the former, it opens but only in read only format.
I know that Macs from like 10.10 (I think) have a different version of samba to windows. Is this strictly a samba issue? What makes me skeptical is that it was also a problem via NFS on the windows server. Then again... Windows NFS is terrible as well.

 

@doug, with your mac server, are you serving purely over NFS?

 

 

[doug shaffer]

Hi, Noface -

 

I'm not sure how files are served over our network.  Since we're an all Mac office, I just used the default (very basic) file sharing setup that comes with the operating system.  

 

Sorry - I don't know more than that.

 

Doug

[jonathanmonitor]

As a test, I have disabled The Mac preview pane and this appeared to allow the files to open without being read-only.

 

I have left it with a few users to test and let me know.

 

Too early to tell if this is actually what is causing the problem however I know windows has a similar issue with the Preview Pane locking files so I wouldn't be surprised.

 

Will feedback if my users inform me that it is working OK.

[jonathanmonitor]

Problem still persisting so back to square one!

 

User accounts also downgraded and problem still persisting.

[doug shaffer]

Darn - I wish I could be of more help.  On the Mac OS X platform, this would typically be a Permissions issue, but as you may have seen from my earlier posts, the problem wasn't resolved until I upgraded all of our computers to the latest OS.  

[PVA - Admin]

18 minutes ago, jonathanmonitor said:

Problem still persisting so back to square one!

 

User accounts also downgraded and problem still persisting.

Same issue happens after restarting the server? The users all have separate account names/no one is logging in with the same usernames?

[Noface]

I think MacOS doesn't seem to like the windows ACLs. There's no documentation on this for recent macOS (their docs have been getting worse or deleted) but they did introduce their own branch of samba that might have affected that. 

ACLs on mac and Windows are natively quite different. e.g.

on a mac:

[mac174:~] noface% ls -le
total 0
drwx------+  9 noface  staff   288 18 Jan 00:45 Desktop
 0: group:everyone deny delete
 

on windows share:

 

drwx------+ 1 noface staff    16384  5 Oct  2017 _SYNCAPP
 0: AAAABBBB-CCCC-DDDD-EEEE-FFFF82000001 inherited allow list,add_file,search,delete,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
  1: group:groupname inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
   2: AAAABBBB-CCCC-DDDD-EEEE-FFFF82000002 inherited allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit
    3: AAAABBBB-CCCC-DDDD-EEEE-FFFF82000003 inherited allow list,add_file,search,delete,add_subdirectory,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
     4: user:noface inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
      5: AAAABBBB-CCCC-DDDD-EEEE-FFFF82000004 inherited allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit
       6: group:admin inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
 

So you can physically see a difference in how they are handled. I think it just doesn't sync up and can cause issues even if you set up permissions correctly. 

I have an environment where all other apps do not have a problem though, only vectorworks which is frustrating.

I think that also because POSIX permissions are simpler and I think are more supported on MacOS, I've had to go for a linux server (cos I don't like mac servers) but also why Doug has had a good time. 

There must be a way around this but doesn't seem like a common workflow in general with Vectorworks users.


I've created a linux server and to make sure that sharing work is easier in general even if permissions have set, set the umask for all users to 002

Additionally, I think sharing via NFS has given me more customization on the type of mount I can do where I can retain the permissions through the mount rather than with Mac Samba which only allows me to log in as the user. 

I think what would work with a Samba set up though is if you have Domain Controller managed user accounts to sort out your permissions (which I haven't done yet).

The linux nfs set up seems to be working well so far and I would recommend it for a storage server to everyone at the moment. (Using CentOS 7.6 server but whatever you prefer would probably be fine.)
 

If anyone has any questions, let me know!

 

[peterlukejenkins]

Has anyone found a working solution to this problem yet? A couple of years ago we had serious problems and ended up replacing our whole server, lots of machines, new software licenses etc. Eventually the solution that worked was to downgrade all users to non-admin status, which worked until now.

 

In the last two weeks we have the problem recurring - lots of VW files opening up in a 'read only' state (the pop-up shown in the OP appears on opening). The files are definitely not in use and this has been confirmed by our IT support who have checked server side.

 

We are running VW 2017 SP5, which hasn't changed recently, so it's strange that it has suddenly started happening again.

 

[StefanoT]

We have been experiencing the same issue, running VW 2020 (latest) on macOS 10.14/10.15 and Synology DSM with SMB sharing.

We've the feeling it may be related to referenced files: when working with 2 files (file A, file B), when a user opens file B (containing a reference to file A), file A suddenly becomes  (and remains) "read-only" till user B logs out. This also happens when file A is already opened by user A: suddenly the open file becomes read-only, and the user loses the possibility to save it and/or write/overwrite file A.

 

Not sure if this has to do with file sharing, file sharing protocols, os and or Vectorworks (or to some/all of them together)

Edited September 7, 2020 by str

[peterlukejenkins]

Hi Str,

 

Just to confirm we are having the problem with all files, whether they include any referencing or not. Most of our files are small projects where we don't need to use referencing, and the issue still occurs.

 

Is there anyone from vectorworks interested in this issue? It seems to be reasonably common.

[Ruben]

Hi peterlukejenkins, 

 

Do you still have these issues? We never had them before, but about 6-12 months ago we started to have this problem as well and it seems to become worse every month. 

It happens both with 2022/2023 files, even with files I just created myself and saved on the server as a test. My MacOS is Ventura 13.2.1 and server is a NAS Qnap in the same network, connected with SMB protocol. I guess not all of my colleagues are updated to the exact same operating system, but since it happens with my own files I just created as well this shouldn't be the problem, right? 

[heavy manners]

Same problem here, just started with some files randomly and for all users on the server.

[TomDK]

Out of curiosity, (particularly for those Mac users out there) are you running any security software (anit-virus, malware etc). 

 

Our office has the same issue and I seem to have found a link when the sercurity software we use (Sophos) is turned on. My belief is that the live scanning feature on Sophos sometimes makes Vectorworks believe it is being used by someone else, but in reality it is just being scanned by Sophos prior to it being 'allowed' to open. 

 

When I turn Sophos off, we have not had the same issue.