In an earlier post I've hinted to an issue concerning Microsoft Office when using it in a networked Mac OS X environment and that it would be solved by using NFS instead of AFP for mounting home directories.
This however was an incorrect assumption, the whole story is listed in this 5 year old post on Mac OS X Hints:
Bottom line is that when you use network homes on a Mac (ever since OS 10, or maybe even longer), then Microsoft Office will expect a “.TemporaryItems” directory in the root of the mounted volume. In most cases it would be inside the root of the “Users” folder on the server.
As I would expect for most organizations, we don't use the “Staff” group. We follow the Unix convention where your primary group has the same name and GID as the username and UID. So the default rights on the “.TemporaryItems” directory usually are wrong from the start. (root:staff)
On top of that, as would be normal a regular user can't create or modify directories in the root of the “Users” folder on the network so the problem can't be fixed automatically either + in most cases the “.TemporaryItems” directory doesn't even exist.
In order to solve this you have to create the “.TemporaryItems” folder inside the root of the “Users” folder located on the server:
$ cd /path/to/volume/or/sharepoint/Users $ sudo mkdir .TemporaryItems $ chmod 1777 .TemporaryItems
This is a slightly modified version of the Mac OS X Hints article. Our users don't have a group “Staff” so setting the group doesn't really solve anything. So we just want everyone to be able to write inside this group, thus setting the “Others” to read and write as well instead of no access.
The content of the “.TemporaryItems” directory is quite safe, regular users will have their own directory inside this one (numbered) which has their own UID + primary GID which in our case is user specific. So nobody can access content from another user.
We've also tried making a symbolic link from “/tmp” to “.TemporaryItems”, this however didn't seem to work regardless of the rights. So, your sadly forced to do it as stated in the Mac OS X Hints article.
This solution should work for both NFS home directories (e.g. your Mac is a client inside a regular Unix network, or you use NFS shares on your Mac OS X Server) and AFP home directories.
As some comments mentioned in the Mac OS X Hints article, this issue might date back to Microsoft Office 98 for Mac and is still persistant in Microsoft Office 2011!
Hopefully someone will find this useful, it took us quite a long time to find the problem due to the brilliantly vague errors from Microsoft Office. Though in the end they were right, users really didn't have rights to read or write. But PLEASE tell us where it's trying to write!!!!!!