Office 2016 Cannot Write to XSAN

LameBeard
New Contributor

I’m having issues with all Office 2016 for Mac (v.15.24) programs being unable to write/save files other than PDF to our XSAN and user homer folders. Excel spreads (.xlsx), word docs (.docx), powerpoint (.pptx) files refuse to be written despite user permissions to the destination being Read/Write. I use OS X Server to set these permissions. The workaround is to save the file locally and then move it to the desired location. When this document is opened again from the xsan location, it cannot be overwritten, it must still be saved locally.

When Office for Mac 2016 performs a save, it saves a temporary directory on the volume first, and then swaps the file with the actual file the user wants to save to (to prevent corruption of the original file). Normally, the temporary directory path returned by Apple's API will be somewhere located in a hidden folder called ".TemporaryItems" in the root of the share where the user has mounted (in our case, /Volumes/Stornext/.TemporaryItems). Normally, access to this location is Everyone>Read Only, but I've set the ACL permissions to Read/Write, with no change. I would like to use OS X Server to change the permissions but Server does not reveal the hidden folder: .TemporaryItems

Microsoft Office 2011 has no trouble writing [.pptx, .xlsx, .docx] files to the xsan, which leads me to believe that something with Office 2016 might be the issue, rather than our san.

El Capitan v.10.11.5
Office 2016 for Mac v. 15.24
Quantum Stornext

1 REPLY 1

Josh_Smith
Contributor III

@LameBeard This is not an exact match for what you describe, but it sounds similar enough that you might want to try the new Insider Fast build to see if it is resolved:

per Paul Bowden (leads Office for Mac at Microsoft) on slack:

Aug 4

we actually made some headway on the Word SMB saving issues this week and think we have a fix. What was happening here was Word was saving the document on a background thread and the OS already thought we were done with the save operation thus causing the sandbox error. The fix is to move the save operation to the foreground thread. The fix got checked in last night and will appear in next weeks Insider Fast build, but if you can reliably repro this, I'd love to shoot you over a private build to confirm that this resolves the issue.

Aug 10

the new build that went up to Insider Fast today has a fix for the Word SMB/network share saving issue where you may have seen an access denied/sharing violation error when saving changes to a document.

If that doesn't do the trick I'd suggest bringing it up on the MS Office channel on Slack if you haven't already. You are likely to get a quick response from the MS folks there.