Office Bug: Slow Saves on Shares

Copper Contributor

Our environment:

Clients: Mostly Win10 22H2 with a few still < 22H2.  Some Win11 on the latest build

File server:  VMWare Server 2019 1809 with several different volumes with a mix if NTFS and ReFS

Word:  Version 2303 (Build 16227.20258)

Users do not have admin permissions to their own PC.


For some time, we have been getting reports from our users that saving Word docs takes a very long time to complete on our file server.  The odd thing was it was only certain shares where this issue took place.  It was a mix of shares on NTFS and on ReFS.  We discovered it’s not only Word but all Office products that we have tried.  (Excel, Word, and PowerPoint).  The symptom was consistent in specific locations on our file server.  Open a Word doc, make a quick change, save, wait ~30 seconds while the popup says it’s saving, then it finally completes.  While in other locations you do the same thing and it is instant.  Does not matter if it’s a new doc or an old one.  Also note we experimented on many different clients and the results were always the same.


One volume was really a head scratcher.  There were 2 different shares on the same volume, one the Office saves took 30 seconds while the other was instant.  If you moved or copied the files between shares, it didn’t matter.  It appeared to be the location that was the issue.


Mind you no other issues were observed.  It was only Office products.  We could actually open the slow save Word doc in WordPad and it would save instantly.  Try again in Word, 30 second wait.  Same with .RTF files.  The file type didn’t seem to matter.  It was only if we used an Office product where we would see the 30 saves. 


We discovered that if we added the user to the server’s admin group, the 30 second save would go away!


Fired up Procmon and did a winword save comparison between the two type of saves.  The 30 second save had an “ACCESS DENIED” right before the long wait.  (See pics).  The Procmon output for the instant saves did also try to do the "Write DAC, Write Owner" but it was successful.






After many days of troubleshooting, we finally found a “fix”.  Most of our shares are setup up where the authenticated users group is in the “Share Permissions” with full control.  From there we rely on the NTFS permissions to allow/deny access to various parts.  This is what we have been doing for many years without incident.  It turns out if we uncheck the allow “Full Control” and leave “Change” and “Read” checked, the Office saves are now instant!


I would like to stress that we have tried several different things and the issue was always with Office products and nothing else.  If feels like there was some sort of Office patch that has caused this issue since this seemed to suddenly occur across the board with no warning.



3 Replies


From what I could understand, you have an error where saving office documents to certain shares on your file server takes a long time. You mentioned that this problem occurs with various Office products and on both NTFS and ReFS volumes. You also mentioned that adding the user to the server's admin group fixes the problem and that you observed an "ACCESS DENIED" message in Procmon before the long wait while saving.

This problem can be related to permissions or security settings on the file server or the specific shares without knowing it exactly. It can be helpful to review the permissions and security settings for the affected shares and compare them to the shares that are not experiencing the issue. Additionally, it can be helpful to check if there are differences in Group Policy settings or network configurations between the affected and unaffected shares.


I hope that I could help you with this.

Yes, adjusting the permissions was the bandage at the end of the day. We had compared the file/folder (NTFS) permissions at length between slow and fast. It wasn't until we looked at the share permissions (as mentioned we almost always set it to give full control to Authenticated Users) that we noticed the difference. It actually was by luck that we had a share or 2 "incorrectly" set from how we normally have it.

Yes, we had looked at the GPO as well and nothing jumped out while we were troubleshooting

The "Fix" we found defies logic.
The users are set for "Full Control" on the share. Then it takes a long time to save and the "ACCESS DENIED" comes up in Procmon...yet it still eventually saves.
It's when we remove "Full Control on the share is when there are no issues. One would think the opposite should be true.

If this was a server permissions issue, the user should not be able to save at all. It's binary. Either the user can or can't. However, in this case, they can....but they have to wait. What??!!

Again, only Office products are affected. Same document and share with WordPad, no issue.


First of all, I'm glad that you came to the solution of your problem.

Secondly, I am a simple user :) like everyone on this forum, not a Microsoft employee or on any dependency or provision basis.

Third, you can provide feedback and/or suggestions for improvement to Microsoft.


I wish you continued success with MS Office 365 :).