Office lock files on SMB share seem to still be present after Office is closed

ms officeNetworksmb

One of our Mac user (macOS 10.12.6) is working together with some other guys who use Windows. The data they are working on resides on a central server which the Mac guy connects to via SMB.

Microsoft Office creates lock files when someone opens an Office document. When the document is closed, these lock files are also removed. The lock file contains the name of the user who has the file opened. With this mechanism Office is able to show a dialog like "You can't save this file as it is currently opened by XXX". The filename is ~$<original file name>, so test.xlsx has the lock file ~$test.xlsx.

The problem is that those files are still visible on the Mac, even when the Office document is already closed. I crosschecked the folder contents from a Windows VM and wasn't able to find the lock files. Also the guy, which the Mac claimed to have the file open, actually didn't had it open.

I have no idea why those files are still shown on the Mac when they actually aren't present anymore. Could this be related to the ~ sign in the name? Or do we have to add some mount options to the SMB share?

[Edit] The computer is connected via Gigabit Ethernet, the building is connected via 10G fiber to the data center. Throughput to the SMB share was around 80MB/s the last time I measured. So, I guess, this doesn't count as slow connection.

[2nd Edit] I don't know about the OS of the central server. But the Mac is connected to an Active Directory which is provided by Windows server (at least I have remote access to a Windows machine where I can manage my department users). The local user account is not connected to the AD, but when mounting the remote share, an AD user is used for authentication.

Best Answer

This happens all the time in my experience for enough Mac clients that hit a server that can’t keep up with the requests. You almost surely cannot change this on the Mac end and need to either deal with broken temporary files or be sure your support organization reviews the performance / loading of the appliance and OS that actually runs the SMB shares.

At best, you could check what version of SMB was negotiated and if you’re using an older protocol, try to force your mac to connect SMB v3 or so. (This is the only time when you might be able to “solve this” on your end)

You can also upgrade to High Sierra as it has a lot of settings changes to make SMB browsing and sharing better.

Things to ask the people that support the SMB share at work:

  • give them specific dates, times, IP address of your mac when you see these issues.
  • give them the full path
  • ask if the storage / disks have convention or performance overload
  • ask if there is a macOS best practices document from the vendor and if they can or plan to implement all the items.
    • Some specific items are patching to recent SMB versions that include things like vfs_fruit extensions, disabled changing permissions from mac clients on file moves, clean up scripts or suppression of things like .DS_Store files, whether .TemporaryItems is writable by all at the root of the share, if they can enable debugging logs for the folder where you save your files or set up a small test share so they can change that to match the “best practices” and see if these orphaned / ghost files no longer happen
  • tell them if you can make this happen reliably and on command - that is gold for them to debug a share - without it they can’t test things out methodically and have to wait for a timing or repeat of the issue
Related Question