I’ve been experiencing an issue with files becoming read-only locked on a Server 2012 R2 file share, typically across the WAN.
Usually once per day at least, we would have a user report that a file had been marked read-only on the file server in an unexpected way.
Here’s some of the instances that have occurred:
- A person is working on a drawing over a period of an hour or two, attempts to save the drawing they’ve had open for a while and receive “file is read only”
- A person goes to open a drawing, gets warning it’s read-only, but the user who previously had it open closed it minutes or hours ago.
- A person goes to open a drawing, gets warning it’s read-only, but the user mentioned in the warning has not touched the drawing since the last restart (perhaps “recent files” holding it open?)
95% of these issues were related to AutoCAD .dwg files, but it occasionally happened to Excel files too.
I used handle.exe from sysinternals to verify that the file was actually opened by a process (acad.exe) and it consistently was; there was just no explanation for why or how this process was opening or holding open the file handle without user interaction or knowledge.
I finally traced this to a series of registry changes that were being pushed out as ‘optimizations’ for SMB, which had been recommended here: https://msdn.microsoft.com/en-us/library/dn567661%28v=vs.85%29.aspx#clients
Primarily, we had defined:
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters
Key | New Value | Original Value |
FileInfoCacheEntriesMax | 32768 | 64 |
DirectoryCacheEntriesMax | 4096 | 16 |
FileNotFoundCacheEntriesMax | 32768 | 128 |
When I reverted these values back to original, the reported issues universally stopped according to my users.
This just speaks to the increased need of change tracking in my organization; it would have been relatively simple to correlate the first reported instance to a set of changes in the same time frame. Implementing that system is easier said than done however.