Wandering Thoughts archives

Enabling NFS v4 on an Ubuntu 22.04 fileserver (instead of just NFS v3)

In Ubuntu 22.04 and other modern Linux distributions, the way you prevent your fileservers from doing NFS v4 is to set some options in /etc/nfs.conf. The default is to support NFS v4, so you need to change that:

[nfsd]
vers4=n
vers4.0=n
vers4.1=n
vers4.2=n

In theory, rpc.nfsd(8) says that setting all of these is overkill and all you need is 'vers4=n'. I haven't actually tested that; we turned everything off. You can set this through /etc/nfs.conf.d/ drop in files if you want to, instead of directly changing /etc/nfs.conf. As I found out, it's not necessary to tell mountd to not do NFS v4, and in any case it also turns out that mountd reads /etc/nfs.conf too for the 'vers...' settings.

But suppose, not hypothetically, that you want to take your NFS v3 only fileservers and make them support basic non-Kerberos NFS v4 as well, because you're in the process of moving to NFS v4 for reasons. What do you need to do, and how disruptive is it? Based on our experimentation, here are the answers for Ubuntu 22.04 fileservers and NFS clients.

• Probably, explicitly configure your NFS v4 ID to name domain in /etc/idmapd.conf. This is normally deduced from DNS information, as covered in idmapd(8), but you may want to set it to be sure that NFS servers (and clients) aren't confused if you have DNS problems for some reasons (which we've had happen in the past).
• If you changed idmapd.conf, restart the server: 'systemctl restart nfs-idmapd'. It's harmless to do this while you're not doing NFS v4, even if it changes your NFS v4 domain.

  (Eventually you'll want to make this change on your NFS clients as well.)

• Reverse your changes to nfs.conf so that NFS v4 is enabled; this is the default state, so just removing your changes is enough.

• Make your new nfs.conf NFS version settings take effect by 'systemctl restart nfs-server'.

A normal Ubuntu 22.04 NFS server already has all of the NFS v4 services you need enabled and started by default (such as nfs-idmapd). It's just that until you enabled NFS v4, they probably weren't doing anything. This makes for a pleasantly minimal change.

You might wonder how systemd restarts the kernel NFS server, since it's not a daemon process that can be stopped and started conventionally. How this works is that stopping the kernel NFS server is done by running 'rpc.nfsd 0', which tells the kernel to have '0' NFS kernel threads and thus shuts down the kernel NFS server. When rpc.nfsd starts the kernel NFS server up again (with some number of threads), it passes in your new 'support v4' information.

(Except it turns out that rpc.nfsd does this by writing information to /proc/fs/nfsd/versions, which is sadly not covered in nfsd(7). This file has an obvious format, but can only be written to if there are no kernel NFS server threads.)

As far as I can tell, this process is transparent to a NFS (v3) client with filesystems mounted or even active at the time you do this on the fileserver. The client may experience a brief pause in NFS server response when the server restarts, but if so it wasn't enough to cause client kernel messages to get logged about it. As you would expect, the client's NFS mounts don't magically get changed from NFS v3 mounts to NFS v4 mounts; instead this will only happen when you unmount the filesystem and mount it again.

(A discussion of NFS v4 ID mapping and why you probably want to explicitly configure your domain is beyond the scope of this entry.)