2

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.

  • 1
    This seems to happen to me whenever an SMB connection is really slow or high latency. Happens for lots of file types, not just MS Office. Best solution is to copy files to local storage before editing. For some reason, making the server use ZFS also made the problem go away—but that's probably not an option (and I don't know why it worked for me.) – Wowfunhappy Aug 9 '18 at 13:44
  • I can't believe that nearly every problem with Apple products results in use something else. – PVitt Aug 10 '18 at 12:19
  • You write "the data they are working on resides on a central server", which is the OS version of the server? If it is Linux, which Samba version? If Windows, is the Mac integrated into an Active Directory environment, that is, is the Mac guy's account bound to Active Directory? Do you know which Office version is being used? – jaume Aug 23 '18 at 19:34
  • @jaume Thanks for these questions. I tried to answer them, however, I'm not sure which Office you meant with your last question. The office of the guy who can't open the file? Or the office of the others who can? Anyway, from my point of view this problem is not related to office. Office works as expected. It's the filesystem on the Mac that is showing files that are actually deleted on the remote server. – PVitt Aug 24 '18 at 8:07
  • @PVitt Thanks for your answers, I was wondering which Office versions your Mac and Windows colleagues were using to rule out possible incompatilbilties between versions and to find out if I could be able to reproduce such an environment. But I agree with you, it is probably not related to Office, it seems more to be some kind of caching problem. – jaume Aug 24 '18 at 8:19
2
+50

This happens all the time in my experience. 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
  • Thanks for this detailed answer. Actually, the connection is using SMBv3. An upgrade to 10.13 is delayed (for reasons), so I went with disabling the local cache. I can't judge whether this works, as the user is currently on vacation, however, as this is the first and only answer containing some helpful stuff, you'll get the bounty. – PVitt Aug 27 '18 at 11:46
  • Thank you kindly @PVitt - we have many production Mac that due to third party limitations, 10.12 is all we can go to. We've had great luck with SMBv3 and disabling metadata collection, disabling .DS_Store writing and not using column view ever, ever, ever. Oh - and turning off icon previews helps as does minimizing quicklook on every file on a slow SMB share. – bmike Aug 27 '18 at 21:38
  • Just a follow up: I recently updated the particular machine to 10.13 and got no more reports about ghost files since. – PVitt Oct 12 '18 at 9:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .