Word and Excel leaving orphaned ~$ lock files on Mac Server

Question

Level 1

136 points

Word and Excel leaving orphaned ~$ lock files on Mac Server

This isn't a new problem, but after a server upgrade I've returned to trying to figure out what's going on. This has probably been discussed thoroughly elsewhere, but my search-fu is weak so not coming up with much that quite mirrors my issue.

Of the many Office app related lock problems, mine is relatively simple: Word and Excel are with some regularity leaving orphaned ~$ files on my Mac server, which causes problems down the line when a different user tries to open the document (they get an "in use" error, as they should).

These are the 162 byte long invisible files (with the same name as the locked file with ~$ added to the beginning) that Word and Excel create when you open a document to let other users know its in use and who has it open. They are supposed to be automatically deleted when you close the file, and some substantial fraction of the time they are.

However, at least a couple times a day, they aren't. The problem is not isolated to a single user or platform--I've seen it on multiple Mac clients (Yosemite and El Cap) running Office 2011 and Windows clients (Win7) running office 2010 and 2016. The files are being opened directly off a Mac server, previously on 10.10 and now fully updated 10.11.

I expect them to be created and left around if Word/Excel crashes or otherwise closes inappropriately, but that doesn't seem to be the cause. Likewise for server disconnect glitches--the server has uptime measured in weeks, and there are no other complaints about disconnect or file errors happening.

I can manually find and delete the problem orphaned lock files, but that's inefficient and I'd like to at least know why they're not getting deleted, if not a way to resolve the issue.

Suggestions? Note that this is unrelated to the oplock/in use problem that seems to be common and have many, many possible causes. This is just the lock file being created but not deleted.

Posted on Aug 2, 2016 5:38 PM

Reply

Answer 1

cdhw

Level 4

3,588 points

Aug 2, 2016 5:52 PM in response to Marc Marshall

Have you followed this recipe, which needed to get Office 2011 to work reliably with Server volumes:

On the server cd to the top of the shared volume and create a .TemporaryItems folder with the following permissions:

cd /Volumes/SharedDisk/.

sudo chmod 1777 .TemporaryItems

ls -la

drwxrwxrwt+ 12 root wheel 408 Oct 13 13:01 .TemporaryItems

If you have already got this set up, next step is to check the permissions and ACLs on your shared volumes. What happens when a user tries to delete the lockfile manually?

C.

Reply

Answer 2

Marc Marshall Author

Level 1

136 points

Aug 3, 2016 12:22 PM in response to cdhw

yes, the .TemporaryItems directory exists at the top level of the share, and has 777 permissions. It contains a number of per-user subfolders, as expected.

Permissions/ACLs on the shared volume are not complex and are configured as expected. Looking at a sample ~$ lock file, the ACL for it shows full control (including delete) for the group containing the user that created it, and no user-specific restrictions.

In the testing I've done so far, the user has no problem manually deleting their (or others') ~$ file. One user who's been particularly bothered by it has invisible files visible so they can manually delete them, in fact. Users can't see them by default, though, and I'm loathe to show them all hidden files just so they can manually get at the lock files that should exist in the first place.

I've had reports of Excel Mac 2016 being crashy, so some fraction of the files I'm seeing are probably someone who had a file open, had Excel crap out on them, and then didn't re-open the file themselves to clear the lock before someone else tried to get at it, but given the number and frequency I'm nearly certain this doesn't account for everything.

One thing that occurred to me as a possible cause is if Excel or Word are crashing on quit, and so not properly cleaning up after themselves and not making it obvious to the user there was a problem (since they were quitting it anyway), it could lead to something like this. But given that I'm seeing these left by users running both 2011 and 2016 Mac, and 2010 and 2016 Windows, that seems like a stretch.

Reply