I've been always eager to test NFSv4 since it was about to be released, but never managed to, for several reasons. Now, having both a Linux and a Solaris workstation on my desk, I decided it was time to give it a try. … My Linux workstation, which is the one I use most of the time, is also an NFS server, and exports my home directory to the Solaris box. Both machines use autofs/automount, so every time a process tries to access /home/bronto or something below that, my home directory is automatically mounted. All worked well with NFSv3, and both Linux and Solaris supported NFSv4 — it's actually the default in Solaris — so why not give it a try? After all, how hard could it be?
Well, the task proved was not that difficult "per se", but finding the right documentation was. After running around in circles for a while with old and outdated documents, I found this howto for Ubuntu, which is being updated into this newer document. They looked good, and much of them seemed to have already been incorporated into the system defaults.
Still, I wasn't able to mount my exports via NFSv4, and I couldn't understand why I always got a "no such file or directory" error message. Until, during my research, I hit this blog post from Oracle's Robert Gordon. The enlightening sentences were:
The linux NFS server implements the NFSv4 pseudo filesystem (pFS) as a separate namespace to that of the server[…]. The root of the pFS namespace is designated in the exports file via the fsid=0 option.
Mounting using NFSv3 our mount command would look like this :-# mount -o vers=3 linux_server:/export/proj /proj
The pFS is customizable by the sysadmin allowing the flexibility to present a different namespace; for our example we may choose to specify that the root for the pFS be /export[…]
we will need to alter the mount command on the NFSv4 Client:# mount -o vers=4 linux_server:/proj /proj
That was the difference I was missing: with NFSv3, you need to use the full path of the exported filesystem. In NFSv4, you don't see the full path, but only the root of the pseudo-filesystem and all exports below it.
Needless to say, everything worked by using the right path. Or I should say everything but one thing: my files on the Solaris box were all owned by the anonymous (nobody) user. What was wrong?
It was research time again, but this time it was quite easier to find what the problem was. With NFSv3, numeric UIDs/GIDs are used; in order to make things work, it's usual to share the same UIDs/GIDs on both the NFS server and the clients. E.g.: the username bronto must be associated with, say, UID 1000 on all systems, and the same should happen for the groups and GIDs. That's probably one of the reasons why NIS was so popular in the past: it made easy for all systems to share this information in a consistent way.
With NFSv4, things change: users are mapped by username, and the mapping between user names and user IDs is handled by a process called "ID map daemon" (idmapd). In particular, NFSv4 clients and server should use the same domain for the mapping to work properly, otherwise requests will be mapped to the anonymous user/group.
Knowing that, making things work was as easy as changing the Domain directive in /etc/idmapd.conf on the server, from "localdomain" to the domain of my Linux workstation, and restarting idmapd. Remounting the filesystem associated users and groups correctly. Now my Solaris workstation automounts my home directory from Linux using NFSv4.
What did I gain with this, apart of becoming more familiar with NFSv4 concepts? Well, not that much so far. I was hoping (or I should maybe say confident) for a performance improvement of my daily home directory copy[*], but it actually took a bit more than usual today. Anyway, a single test doesn't make a statistic, so we'll see how it develops during the next week.
[*] every day I have my home directory synced to a ZFS filesystem on my Solaris box. Coupled with the rolling snapshots mechanism (Solaris' time machine), this sync gives me a good number of snapshots of my home directory, where I can hopefully recover files I unfortunately removed and are not in my other backups any more. Having many files in my home directory, and many directory levels, rsync takes about four minutes every day to complete on NFSv3. I hoped that the process would get a performance boost on NFSv4, but it didn't at the first time.