MS Office and Network Volumes

From Provider Wiki

Jump to: navigation, search


Many users use network shares to store their documents on the (good) advice of their LSP's, but users who try and work with Microsoft Office documents that live on a network volume while using a Macintosh can be in for some rude surprises. If they try to save a document (new or old) directly on a network share they might get error messages something like the following:

"Word cannot save this document due to a naming or permissions error on the destination volume."

or

"There has been a network or file permission error. The network connection may be lost"

These error messages may change, and are not actually very useful in troubleshooting, as they are the catch-all error messages when you save a document. But there are a least two things that you can do to try and minimize the problems that your users will see.

Another characteristic of these problems is that the user can successfully create the file locally, then copy it to the network share. It is only when they are trying to work on the file directly from the network share that this fails.

Configure Norton "Safe Zones"

As we at UPenn have a site license for Norton Antivirus almost all of the computers on campus should have a copy running on them. And generally it is a good product, but when it comes to network volumes it can have a bad interaction with some programs, especially those from Microsoft and Adobe.

The cause of the problem in this case is that Norton's "Safe Zones" feature intercepts all reads and writes to the hard drive in order to scan the files, and in doing so slows down the process a little bit. This delay causes MS Office to think that the write is not going to succeed and it panics. Sometimes this means that the file does not get saved, sometimes it is successfully saved (despite the error message).

The fix for this issue is to re-set the "Safe Zones" to only the local hard drive, explicitly excluding network volumes. Unfortunately you cannot just exclude network volumes, so you wind up excluding any removable media you might have. Generally this is still ok because those volumes should be scanned when they are inserted anyways. And your network volumes should be scanned by the servers that host them, so you should be ok there as well.

.TemporaryItems on the network share

A second problem that you might run into is that Office (generally Word is the most problematic) wants to write to a ".TemporaryItems" folder on the root of any network volume that it is writing to, ideally a hidden folder (the period will probably do that for Mac clients). This is generally a bigger problem when you have someone working with a "group folder" or "user folder" that is being shared from a Windows server. In those cases users generally only have permissions in their own folders within a network mount point (such as GROUPS$ or USERS$), and have no rights at all to the root of that share. What happens is that Word (or other MS Office programs) tries to create this folder (or folders and files within it) and when that fails it complains to the user about it.

The solution is rather simple for the server administrator: you just need to create a hidden folder named ".TemporaryItems" (the period before is required) at the root of all of your network shares and give read/write/create/destroy rights to all files within that folder to all users who would be connecting to those shares. Once you do that then the problems should go (mostly) away.

There is a slight secondary issue to this one: Word uses the uid of the user on the computer it is running on to create a working folder within the ".TemporaryItems" folder. If the users who are connecting to the network share are using local accounts on the Macs that they are working from (that is not using ActiveDirectory or OpenDirectory accounts), then their user IDs will almost all be 501. This means that they will all be using the same folder. Usually this does not cause any problems (as long as the inherited permissions on the server are created correctly), but it is something to keep in mind when you are troubleshooting.

It has also been reported that in some circumstances if a user shuts down their computer with their network home directory still connected that the entire .TemporaryItems folder could be wiped out, thus wiping out the temp files for other people as well and causing error messages on those clients. There is not enough information about this to avoid the issue altogether, but it is worth knowing for troubleshooting purposes.

References

In researching this document the following web pages were used: http://www.macosxhints.com/article.php?story=20051122213207398 http://www.macfixitforums.com/showflat.php?Board=OfficeX&Number=631995 http://word.mvps.org/Mac/CantSaveToServer.html

Personal tools