Trying out NFSv4 (on Linux and Solaris)

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.


4 thoughts on “Trying out NFSv4 (on Linux and Solaris)

  1. Anonymous writes:Note both these problems have been or are being fixed–recent Linux servers don't require the fsid=0 trick (they just export the same paths as NFSv2/v3). And recent Linux clients (and soon, servers) will also allow numeric id's. (Not really condoned by the original RFC but since grudgingly accepted since they're such common upgrade hiccups.)

  2. Thanks for your comment. I'd be interested in knowing which Linux distributions are actually "fixing" things the way you said: if you could elaborate on that, that would be much appreciated.As for the fix itself, a friend of mine had a t-shirt with a big writing that said: "there is no solution", and a smaller one below: "because there is no problem". The fsid option and the pseudo-filesystem, or usernames instead of UIDs are not a problem, really. The real problem is: no one cared writing decent documentation, and explain users where configuring an NFSv4 server was different than in previous versions.That's really bad that we crap on the RFCs instead of fixing the real problem.

    • Hi Matt
      I’ll have to speak off the cuff here. I am not sure I understand the question and, in addition, I don’t have a Solaris machine any longer. And thanks Oracle we may not have Solaris any longer either…
      If you have /projects instead of /exports, you’ll use the same commands with /projects/project_name (for example) with NFSv3 and /project_name on NFSv4 with pFS. Not sure if I answered your question?
      — bronto

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.