Integrating Mac OS X Tiger into our existing NFS/NIS network has proven to be, shall we say, not entirely uninteresting. For one thing, NIS under Mac OS X Tiger does not seem to support supplementary groups! (Update: Mac OS X 10.4.3 does support supplementary NIS groups. I believe earlier versions (pre-tiger) did so as well.) As for NFS, consider the following setup:
The NFS server exports /home to all clients. /home contains symbolic links pointing to the actual location of the users home directory, which is located on another export. For example:
$ ls -ld /home/jschauma lrwxr-xr-x 1 root wheel 31 May 29 2001 /home/jschauma -> /usr/people/cs/student/jschauma
The client NFS mounts /home and /usr/people, and everything should work just fine.
Now, when letting users log into the Mac OS X clients, it turns out that a few number of users can log in, but get the error message that the user's ``home directory was not found in the usual place or cannot be accessed''. However, the users files in his home directory are available and his preferences are saved.
Poking around reveals that the permissions on the symbolic link of those users were:
$ ls -ld /home/username lrwx------ 1 root wheel [some date] /home/username -> /usr/people/hum/student/username
Note: on Mac OS X, this command would have yielded:
$ ls -ld /home/username ls: /home/username: Permission denied lrwx------ 1 root wheel 1 Sep 22 14:58 /home/username
So... this error message only happens if the symbolic link in /home itself (ie /home/username) was created with permissions that do not allow others to read it (the link, not the directory pointed to by the link!). If opened in the 'Finder', the link would show as a regular, inaccessible file. It seems that on Mac OS X (or Darwin?) the file permissions of a symbolic link are actually considered. Note, however, that stat(2) on that platform actually states:
Unlike other filesystem objects, symbolic links do not have an owner, group, access mode, times, etc. Instead, these attributes are taken from the directory that contains the link.
This does not seem to be the case, as in this example
/home is mode 755. So, in order to get rid of the warning (which
is inaccurate and actually benign anyway), the symbolic links had to be
removed on the NFS file server and recreated with the proper permissions.
September 22, 2005