// Mac OS X Server - Microsoft Office & network homes issues

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!!!!!!

     

// Mac OS X: NFS instead of AFP for home directories

This is a rather interesting thing I've come across, using NFS as protocol instead of AFP for home directories.

Changing the protocol fixed several annoying issues for us:

  1. Microsoft Office can now save files in your network home!!! With AFP you'd get the annoying error saying it can't store on a network volume. With NFS you don't get this error, it just works!
    • MS Office also had issues with just saving a file in your home folder, this issue is now gone as well.
    • OmniGraffle also had a similar issue with saving files in your home folder, this is also solved.
    • TextWrangler also had issues with saving in your home folder, 1303 error if I remember correct, this is now also solved.
    • I'm not aware of other applications but at this point I'm very happy with getting rid of these errors!
  2. Login with multiple network users onto one Mac. The AFP protocol doesn't support user switching of network users, NFS does which helps us out allot for certain computers where multiple people work behind.
  3. The default archive utility now works.
    • This used to give errors when using it with your AFP home directory, this basically meant that it was unusable. We were forced to use Stuffit Expander in order to make file extraction possible.
    • Now we can use both without any errors.
  4. And as a last big thing which was fixed for us, the main reason why we now use NFS, is the overall performance.

Let me explain the last point because that's something that won't count for everyone. (and give a small impression of our setup)

     
Navigation
Recent Comments
QR Code: URL of current page
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported