Office Won’t Save To Server

The Art Department is cranking out proposals. Marketing is knee deep in spreadsheets. Everybody's working furiously, when suddenly the panicked phone calls start. The Macintosh users can't save their Office documents, and these cryptic messages appear when they try:

There has been a network or file permission error.
Save not completed. File rename failed.

No matter what you do, you can't seem to get Word or Excel to save to your network shares. You've gone over the machines repeatedly, and everything is set up properly. Worse still, the problem's intermittent. Your users swear it happens when they're busiest, but sometimes it doesn't happen for days.

There is an explanation. What they're suffering from is an unfortunate side-effect of how Microsoft Office handles temporary files, and the more users that are on the server at one time the more likely this is to bring work to a screaming halt.

Why Office for Macintosh breaks some offices:

Most modern applications utilize temporary files, to guard against data loss or free up working memory. Traditionally, Unix operating systems have saved these files in /tmp (though Mac OS X utilizes /private/tmp), and have included random numbers in their names to prevent accidental duplication. Adobe Creative Suite uses a similar method, saving temporary files in the same directory as the open file being edited, but again using a pseudo-random string like ~file~ve_kv.idlk.

Microsoft Office, on the other hand, saves temporary files at the root of the server volume you're working on, in a folder named .TemporaryItems/folders.UID (where UID is the user's account number on their local client machine). This is client-side behavior on the application's part, and can happen when saving to AFP (Macintosh) or SMB (Windows) volumes.

The problem is that users often all have the same UID on their client machine, because Macintosh computers in an unmanaged environment assign a default UID of 501 to the first account created. That means every Office 2004 user is trying to read and write to the same temporary folder. That works fine until the original user logs out of their system, at which point they automatically and unintentionally delete that folder, and the remaining users can no longer save their documents to that volume.

There are two approaches to eliminate this problem, one utilizing directory services on the server side, the other using the Terminal on each individual client machine.

Office for Macintosh in enterprise settings:

In a server setting, Apple expects user accounts to utilize a directory service like Microsoft's Active Directory or their own Open Directory system. Most Mac users expect that they can set up their office machines in the same easy way they've set up their home machines for years. It's these conflicting expectations, wrapped up in Microsoft's predictable file-naming scheme, that create this problem Office users have been left trying to work around for years.

The best solution is to leverage Open Directory on your OS X server and migrate your client machines to a unified, managed login scheme. This not only solves this Office problem but brings a wide range of additional features with it. It's the management structure that allows control of System Preferences and Software Updates for every Macintosh in the organization, enables a company-wide address book for contact management and collaboration, and provides the highest level of security for network resources. In this situation, each user has a unique account not just on their own machine but across the entire network, sidestepping the Office UID conflict entirely.

In environments without a Macintosh server the same principle still applies. Open Directory can integrate seamlessly into an Active Directory domain, allowing Windows administrators a greater level of management control through group policy setup. Instead of using local accounts on each client machine, you can also avoid potential UID conflicts by binding the Macintosh clients to the AD domain and having users log in with their Active Directory domain accounts.

Changing individual UIDs manually:

If you're not quite ready to take that leap, it's relatively simple to change the UIDs on each client machine to match those on the server. It can also potentially destroy a system, so you'll want a recent backup handy and some comfort with the Unix command line. Remember that you'll need to perform these steps for every user on every machine that accesses your server.

Log in as a local administrative user (and not the user whose UID you're changing), and from the Terminal type:

id -u USERNAME

Here USERNAME is the short name of the user to whom you're assigning a new account number. This will give you their current UID. To change that UID on Mac OS X 10.4 type:

sudo niutil -createprop . /users/USERNAME uid NEWUID

On version 10.5, niutil has been deprecated, and instead you'll need to input:

sudo dscl . -change /users/USERNAME UniqueID OLDUID NEWUID

Above, OLDUID is the current account number that the previous command provided, most likely 501 or 502. NEWUID is the new and unique account number you're assigning. Finally, type:

sudo find / -user OLDUID -exec chown NEWUID {} \;

This last command will locate and assign ownership of all the user's files to their new account number. It can take quite a while, depending on how much data belongs to each user. If you use external hard disks or USB drives you'll have to repeat this step for them as well, replacing / with /Volumes/DEVICE (where DEVICE is the name of the external volume).

Once you're done, your users will finally be able to save Office documents dependably. And you can rest easy, knowing that Office 2008 is right around the corner.