I've been saying grumpy things about NFS v4 for a fairly long time now, and in response for a while people have been telling me that these days NFS v4 can look basically just like NFS v3. You can have your traditional Unix permissions model (the NFS without Kerberos one) and you don't have to reorganize your exports and so on. Recently I decided to give it a try on some scratch virtual machines running our standard Ubuntu 22.04 LTS setup, and to my pleasant surprise it does seem to just work.

To test, I installed Ubuntu's NFS server package, made a scratch directory in the same place we'd use for a real ZFS filesystem on a fileserver (which is not under /exports), put in exactly the same export options and permissions in /etc/exports.d/<file>.exports (including 'sec=sys'), and NFS mounted it on a test NFS client. Then I used it on the client as both a regular user and as 'root', testing with root squashing on (our normal setup) and off (used for some filesystems). All of this worked, with none of the various glitches that have happened to us in the past when we tried this sort of thing.

Part of the reason it worked this transparently is that the client and the server both had our standard /etc/resolv.conf and had their hostnames in a standard format (and have fully qualified domain names in the same subdomain). My understanding is that this matters because for 'sec=sys', NFS v4 clients and servers need to agree on a NFS v4 domain name to insure that login 'fred' on the client is the same as login 'fred' on the server. This 'domain name' can be set explicitly in idmapd.conf(5), but if you don't do this it's derived from the DNS domain names of the hosts involved. In a production deployment, we'd probably want to set this specifically in idmapd.conf just to avoid problems.

I suspect that there are other traps in actual use. One thing I've already noticed is that the kernel client code doesn't appear to log any messages if a NFS v4 server stops responding, unlike with NFS v3. These messages are useful for us for tracking NFS server problems and seeing when they start to go away. Possibly there's other signals we can tap into.

My interest is because NFS v4 seems to be better regarded in general and especially for file locking (which is integrated into the protocol in NFS v4 but is a separate thing in NFS v3). My impression is that the Linux kernel NFS people would rather you use NFS v4, and so NFS v4 is likely to get more bugs fixed and so on in the future. (Possibly this is incorrect.)