Sharing Violations

In my case the problem occurs only with Excel, and only with some files...with others theres is no problem at all. Also, it only happens when opening files in our network share. Any tips? 

We are  in the same position, antonioj.f. It's only an issue with Excel (although I work primarily in this app so issue has had more opportunity to occur); only occurs when saving on network shares (on both our Windows file-servers, one remotely-located using SMB, one local spoofing AFP); and only occurs with some files and with no apparent consistency or cause (doesn't seem to be influenced by file size, file type (.xls/.xlsx/.xlsm), or whether a new or re-opened file).

Having tried everything suggested in this thread, the only successful solution for us has been to roll back to v. 16.29 of Office (and disable auto update!). I have not once encountered the issue since running the older version. Until MS acknowledge the issue and announce a fix I'll be sticking with 16.29.

Not really unfortunately, but it sounds like an OSX permissions issue.  The fact it only happens in a network share would support that - I presume that in your case, alternatives that work are files in users home directories.

Have a think about the commonality of users who create the Excel files that work/don't work vs other apps that work.  Are there lots of users involved, some who can, some who can't?  If you open a file that you can't save does it tell you it is read-only?  What happens if you open the Get Info pane on a file and click on locked then open it - does Excel report it is read only?  What is the difference if you open a file and then get someone else to open that same file - does it flag an issue for that second person?  

Can you set up a test using that info plus the info I give above?  As a thought, create a folder on that share, put files that work and don't work in it, set up a group and add users to it then assign permissions to the group and folder and see what happens.

Those are rhetorical questions to give you some more pointers in tracking it down.  I'm trying to think what could be done in an application that would cause it to NOT flag up as read only but then prevent saving and I can only think of permissions that aren't immediately transparent.  What I found is that looking at permissions via Get Info doesn't help: in my case, the file had read & write permission for myself, my wife, everyone, staff, wheel and so on.  Didn't matter, it didn't work: I had to set up the group and set the permissions as I note above.  Something that I couldn't narrow down was higher in the permissions checking sequence that was preventing us as users from updating it, only the Owner was allowed to do so.  I think Catalina has really cracked down on security which might be why it hasn't been a problem previously.

However, having said that, others like yourself, have said it only affects Excel, worked in previous versions etc so we could be dealing with different problems, I really don't know, sorry.

In my case the problem occurs only with Excel, and only with some files...with others theres is no problem at all. Also, it only happens when opening files in our network share. Any tips?

I too had this problem and I'm not sure when it started, however the recent update to 16.34 did not fix this.  However, in my case at least, it wasn't a Microsoft problem although the symptoms shown in this post did appear and did so only fairly recently.  The problem occurred irrespective of the application used - e.g. creating a file in the textedit app.

The symptoms I experienced were that I could create a file and update it no problem, but my wife could only read it - an attempt to update it was met with those error messages about sharing violations.  Vice-versa applies as well.  We were trying this with a file in a Shared folder - the one OSX creates in the /User/ directory when you have multiple IDs set up.  I can't remember if we'd used this directory to share files we'd both want to update in the past or not now unfortunately so I can't tell if it is an issue that arose with Catalina.  Interestingly (or frustratingly), no application (Office or otherwise) indicates that it is opening the file for Read Only, only giving the errors when a save is attempted.

So I can't say this isn't a Microsoft problem as there may be more things going on for some people - others seem to have cleared it up by rolling back to an older version or giving the application full disk access rights through Preferences (this didn't work for me.)  It could be that OSX Catalina is being more strict about application of rights (perhaps fixed old bugs!) coupled with changes to some apps.

What did work for me is to set up a new Access Control List (ACL) and assign it permissions then assign it to the folder and contents.  In Preferences, Users and Groups, add a new Group - say, SharedEdit - and add your user(s) to that group (tick the ids).  Then in terminal run this command:

sudo chmod +a "group:GroupName allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" "/Users/Shared"

GroupName should match the name of the group you just created, e.g. group:SharedEdit

The last part of the command should be a path to the folder that your file(s) are in, e.g. "/Users/Shared"

For some reason I don't fully understand, but is related to the way OSX (Posix) applies permissions, it's not enough to set permissions through the folder's/file's "GetInfo" pane.  

Further, if the folder or file is on a drive that is removable, open GetInfo on the drive itself and make sure that "ignore ownership on this volume".  It should get set automatically if OSX recognises such a drive but it's worth checking.

I've tried several suggestions, including amending security settings to grant Excel 'Fully Disk Access', but the only thing which has worked for me is rolling back to version 16.29 of Office 365.

I have version 16.3x on a different machine and that suffers from the problem.

It would be great to get acknowledgement from Microsoft on this issue, and an update on when it will be patched, so I know which update contains the fix without going through a painful trial-and-error process.