You are now able to browse NFS shares from Mac OS X Tiger computers both from other OS X Tiger computers and from non-Mac UNIX computers. You also have the knowledge to be able to browse non-Mac UNIX computers from your Macs. At this point, there are a few further notions to discuss:
When you create a new user account on Mac OS X, the computer chooses an available userid for that account and creates a group with a matching groupid. If these IDs do not match between NFS clients and NFS servers, the result is usually that the client can read files from the server, but can neither change them, delete them, nor create new files on the server. To fix that problem, one can either apply very permissive permissions on the server, one can use options in exports to remap userids and groupids from a client to their counterparts on the server, or one can fix it so that user and group ids match on all of the computers concerned. This page describes changing uids, but it omits a crucial step: once you have changed userids, you should reboot into single-user mode and change ownership on all of the files that had your old user and group ids over to your new user and group ids (this can take a long time). To boot into single-user mode, you hold down cmd-S as your machine is restarting. You will see a bunch of messages scroll by, and then you will end up at a prompt. Type the following commands (assuming you have a single disk drive and/or a lot of time on your hands:
Replace olduserid with your old numeric userid, and newuserid and newgroupid with your new values. If this sounds scary to you, then please research it further before trying it. It can break things on your machine, due to permissions failures.
When you type that find command, go have lunch, coffee, dinner, etc. In fact, you might want to do this at night, so that it can be finished by morning. If you have a lot of drives, you might do them one at a time, as this is very time-consuming. In the end, all of your permissions will work, though, provided all of the ids match across machines. It’s least painful to do this on a brand-new machine that has not yet accumulated a lot of stuff.
This topic is too large for this article. Suffice it to say that to use NFS effectively at work, you would be best served to make your account on your computer have the same userid and groupid as your accounts at work have. NIS is an effective way to do this for a desktop machine, but setting up NIS is beyond the scope of this article. Please refer to the further reading section, below. NIS is ill-suited for a notebook, as you will often be using a notebook in places where it cannot contact the office NIS server.
The automounter can also obtain information about NFS shares via mapping files and via LDAP. See sial.org’s automount page for descriptions of these techniques (which I have not personally vetted).
Frustratingly, one of the places that OS X’s automounter falls short is in dynamically generating mount definitions. That is, it does not work in the same way that a traditional UNIX amd or autofs automounter works, allowing one to simply cd to a root path and a remote server’s hostname and share path, (e.g., /net/somerandomserver/somerandompath) without first having to define the mount in either NetInfo, a mapping file, or LDAP. I have made some rudimentary starts at scripts that can create and destroy mounts in NetInfo from the command-line, but I have had limited success in using them, and I have not dug into finding a way to invoke them as event handlers so that they function transparently.
OS X’s automount command has an undocumented -host option that I have had very limited success using. It almost, but not quite, provides the same functionality that amd and autofs provide, via using hostname resolution of the target server, but I probably did not have it configured correctly (it’s undocumented, after all). Perhaps Apple will improve this in Leopard.
If you use a traditional UNIX automounter heavily at work, and there is a standard naming convention to get to automounted directories (e.g., /net), you can certainly make life easy when you are working in the Terminal by making a symbolic link similar to the following:
Replace /net with whatever convention you wish to use. Now, in Terminal, you can trigger one of your predefined automounts simply by cd-ing into it or by accessing a file in it:
This would be a fine project. An installer could patch the NFS startup script and create the NetInfo skeleton, then prompt the user for some initial share and mount entries, and finally start up NFS. I’d like to get to this, but if you get to it first, drop me a line.
If you found any of this helpful, contact me. If you have corrections, additions, or suggestions, contact me.
$Date: 2007/01/11 17:58:48 $