Sharing Violation on Windows file servers when saving/editing documents with Excel/Powerpoint for Mac 2016

RagingKoala
New Contributor

Greetings!

We are having an interesting issue at our company. Using both PCs and Mac computers by the creative departments. When we try to save an Excel/Powerpoint file on our Windows file servers we get a sharing violation error, the permission table gets messed up and the file cannot be re-opened again until our server guys re-inherit the rights on the file servers. All Macs connect via SMB.

84bfe665a709400482f89131f5594f9b

The Macs are running El Capitan (not fully up-to-date, 10.11.4) and the Windows file servers are all Windows Server 2012 R2. Previously not just excel sheets and powerpoint presentations had this problem but all other files as well. The servers are utilizing DFS and we also have Talon File Services installed.

We are granting access to the servers via Active Directory groups, two different ones, one for read-only and one for read/write. When the issue happens the file loses all individual and group rights in ACL, only the currently editing user is there with read/write access and everyone with no rights, but nobody can open the file again.

a35fb90bd47f45f184de49423ddafeba

While a healthy file looks like this:

ae4cc41ebaa44d49bbb4dde8b2487204

We did some testing as well with different methods:

  1. We created a SuSe Linux server where we proxy'd the shares using MSDFS but we still got Sharing Violation.

  2. On the same server we created a simple Samba based share but the results were the same.

  3. If we create a Samba based share on a Mac of course that works.

  4. I tried to force it from client side that the Macs should use SMB1, that works too but Excel and Powerpoint still acts up.

  5. As a final charge I swapped Apple's Samba with the "free" Samba available on the internet, solves all problems as well, except Excel's and Powerpoint's sharing violation.

Also we have some servers where we made the AFP protocol available via ExtremeZ-IP/Acronis Access Connect, we don't experience any problems there but we can't utilize it on our other servers where Talon File Services is active.

I'd also like to note that where we are granting access directly not through AD groups, those drives doesn't seem to be affected with the sharing violation.

I also created a case at Microsoft but I'd like to hear/read what's your experience or suggestions regarding this.

(This is my first post here, sorry if I messed up something.)

Many thanks!

Regards,

22 REPLIES 22

dprakash
New Contributor III

Join the microsoft-office channel on Slack, there are Office for Mac devs in the channel. There are known problems with Excel 2016 and Powerpoint with SMB shares. (we get them too)

also make sure the hidden folder .TemporaryItems at the root of the volume has full access permissions

https://kb.acronis.com/content/46936

millersc
Valued Contributor

Which version of 2016 are you running? 15.18 maybe? There was a bug in that rev that the folks in the Slack Office channel acknowledged and appears to be fixed in the latest. Seems some code from Word didn't make it into the other two core applications.

dpertschi
Valued Contributor

Yep, same issue here too.

We have a case open with Microsoft, they have acknowledged the problem and that they have multiple large customers reporting the same.

Swift
New Contributor II

Try changing your share permissions to prevent normal non-admin users from being able to modify ACLs. See if it helps.

Olivier
New Contributor II

Since Office 2016 early versions, and until v15.20 if I am not wrong, we had issues with Pwrpoint (and sometimes Excel, while Word was ok) with files stored on NetApp-based SMB shares, where the file was set to 0 bytes, simply after pressing Save button (saving file locally, then copying using Finder was working OK).

From what I was told, the issue was on NetApp side (maybe not conforming to latest MS SMB protocol/features?), but MS probably probably silently fixed it using another method to write on the SMB share starting 15.21/15.22, so problem is now gone.

As you used a non-MS SMB implementation, maybe you will hit similar issues we had with NetApp SMB.

You can see why you get the sharing violation using Wireshark : in our case, when pressing Save button, the app tried to delete then save the file with same name, but write attempt was denied because according to server, there was still an existing write lock on that file, so app could no longer use that filename (file becomes 0 bytes big) and displayed an error message...

RagingKoala
New Contributor

Thanks guys for all the answers!

@millersc Yes, we are using 15.18 to be honest I never looked for updates because when I hit the check for updates in any Office apps it just gives me that I'm up to date. I looked up some and downloading them at the moment, will try tomorrow again!

@Olivier Wireshark great idea, I will check that out as well!

Thanks again everyone!

millersc
Valued Contributor

@RagingKoala the new 2016 apps need to be opened once to see if updates are needed. Not sure why, never looked deeper. During testing I usually will launch the 3 core apps and then run the updater again to see if nothing is updated, or check the macadmins page if I'm also looking for a new volume update to repackage.

RagingKoala
New Contributor

Haven't had much success with wireshark or newer versions of Office unfortunately.

What I started to notice is that on shares where the .TemporaryItems folder is under my ownership (I don't know or understand how that happens) I can safely save and edit Excel and Powerpoint files.

When I do the same on a share where .TemporaryItems is "not mine" I get sharing violation.

Wireshark was showing a lot of "object not found" and "access denied" error messages on the "faulty" shares. Also when I check from Powershell on a Windows machine I can see that the ACL entries are sometimes duplicated or even triplicated on shares where I'm not the owner of Temp. For example this is a file that is editable but if I create a copy from it and try to save I get sharing violation.

c2b4c3bb1a75484c8d460bdf769152a2

A file that has no problems looks okay, otherwise all non-Excel and Powerpoint looks like this:

e39de1053dff4e90bdefd9dc0a59232d

According to Microsoft they've seen that before and might have fixes, tomorrow the MS supporter should contact me, I'll be sure to share the solution with you if we found any.

RagingKoala
New Contributor

So, Microsoft admitted that it's a problem in their product and their development teams started working on a hotfix. When that will happen, I have no idea :)

Thanks for all the help, we have to wait out the results.

mycosy
New Contributor

@RagingKoala I have the same problem which seems to be affecting Excel files only. I am using a brand new Mac Mini running macOS Server. Did Microsoft provide you with a solution?

millersc
Valued Contributor

@mycosy We've had this happen a few more times. Our network team was digging in and found this to be a "modify" bug issue. If users didn't have "modify" rights at the share level, they got this error. Most definitely an odd problem. I'll see if they found documentation on this or if it was just trial n error.

dpertschi
Valued Contributor

One of the MS software engineers said on Slack last week that they "now have a reliable internal repro of the Word and Excel save issues when re-sharing over AFP. We have engineers debugging this right now."

Fingers crossed.

gkotlinski
New Contributor

According Microsoft, this problem is resolved in a recent update. They also stated that upgrading to 64 bit Office for the Mac has fixed the issue.

https://support.office.com/en-us/article/Fixes-or-workarounds-for-recent-issues-in-Excel-for-Mac-b8d3cd00-a01a-489b-b4de-e27d5cf38851?ui=en-US&rs=en-US&ad=US

https://support.microsoft.com/en-us/kb/3187505

EdLuo
Contributor II

@RagingKoala

Was your issue resolved? We are experiencing the same issue where Excel saving on a SMB share will reset the ACL permission. My test machine is running 10.11.6 with the latest security updates and Excel 2016, ver 15.30

gkotlinski
New Contributor

We still have 1 user that is regularly experiencing the issue. Microsoft sent us on a chase. Told us it was not their issue. We should open a case with Apple. We did that. Then suddenly MS released an Office update that was supposed to fix the issue. They've since released 2 more updates that also are supposed to fix this problem, which they say is not their problem. None of those have worked either. The 64 bit Office update was also supposed to fix the issue and it has not. We're still working on the issue with Microsoft.

andymcp
New Contributor III

Has anyone found a workaround for this issue? I updated to 15.31 and still can't re-open saved files on an SMB share.

jamesgreenMatte
New Contributor II

We are having the same issue. It will be fine for one version of Office 2016 but then when a user just upgraded to 15.31 the problem is back again. Very frustrating. Its very inconsistent from one user to another.

rjacksonx
New Contributor

Some of macOS 10.11 El Capitan users are experiencing the same MSO 2016 for Mac sharing violation error trying to save to a samba share via SMBv2. We are able to reproduce the error with MSO 2016 16.12, the latest, or 15.33. There is no error if macOS 10.12.6 (Sierra) or 10.13.4 (High Sierra) are used. We are not sure if the fault is with MSO 2016 or macOS 10.11 at this point. Anyone else see this? It appears an invite from someone that is a member of slack microsoft-office is necessary to join the channel/workspace.

DanJ_LRSFC
Contributor III

We also have this Office permissions issue on occasion, can it be fixed by updating to the latest version of Office 2016 for Mac? Our environment is a mixture of 10.11 and 10.12 macOS versions.

rjacksonx
New Contributor

Dan, the only solution we found to work is to upgrade the macOS from 10.11 or older to 10.12 or newer. Updating Office 2016 for Mac does not resolve the issue.

anafletcher88
New Contributor

Use longpath tool, it is effective. 

MartinMiller23
New Contributor

Use longpath tool, it is good one.