nfs downgrading from 4.2 to 4.0 depending on the client machine while theoretically capable of 4.2 - why?
I'm playing around with NFS to test some client options.
Before going with the "options" thing, I just test a "by-default" connection from a couple of clients to a given server, so later I'll be able to compare optionized behaviour i contrast to the default behaviour.
But I observe that the clients are behaving differently even if they are both based on ubuntu:20.04
and both have the same version of nfs-common
installed.
Here's the setup:
Server
Ubuntu 20.40 within a bridged virualbox exposing IP 192.168.3.81. Server is the default package of ubuntu 20.04.
Those are the installed NFS packages:
xavi@iridio:~$ apt list --installed | grep nfs
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libnfsidmap2/focal,now 0.25-5.1ubuntu1 amd64 [installed,automatic]
nfs-common/focal-updates,focal-security,now 1:1.3.4-2.5ubuntu3.3 amd64 [installed,automatic]
nfs-kernel-server/focal-updates,focal-security,now 1:1.3.4-2.5ubuntu3.3 amd64 [installed]
xavi@iridio:~$
This is the exports file:
xavi@iridio:~$ cat /etc/exports
/files/repos/sharedfolder *(rw,sync,no_subtree_check,no_root_squash,insecure)
xavi@iridio:~$
CLIENT # 1 (Virtual Box)
The very same server machine on virtualbox can be tested as a client to itself. When mounting, it really uses protocol 4.2:
xavi@iridio:~$ sudo mount -vvvv 192.168.3.81:/files/repos/sharedfolder iridio/
mount.nfs: timeout set for Tue May 4 10:41:51 2021
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.3.81,clientaddr=192.168.3.81'
xavi@iridio:~$ echo $?
0
xavi@iridio:~$
This is the expected behaviour: Client able of v4.2
, server able of v4.2
, then connect via v4.2
.
The kernel in the VBox is 5.4:
xavi@iridio:~$ uname -a
Linux iridio 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
xavi@iridio:~$
CLIENT # 2 (Docker)
Then from the host machine I launch a docker container also based on a raw ubuntu:20.04
and install nfs-common
. Here's the complete session:
xavi@msi-laptop:~$ # Launch a fresh container from an empty official stock ubuntu image:
xavi@msi-laptop:~$
xavi@msi-laptop:~$ docker run -it --rm --name=nfsclient --hostname=nfsclient --privileged=true ubuntu:20.04
root@nfsclient:/# apt-get update > /dev/null
root@nfsclient:/# apt-get install -y nfs-common > /dev/null
debconf: delaying package configuration, since apt-utils is not installed
root@nfsclient:/#
root@nfsclient:/#
root@nfsclient:/# # Check installed nfs packages. Client is the same than vbox.
root@nfsclient:/#
root@nfsclient:/# apt list --installed | grep nfs
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libnfsidmap2/focal,now 0.25-5.1ubuntu1 amd64 [installed,automatic]
nfs-common/focal-updates,focal-security,now 1:1.3.4-2.5ubuntu3.3 amd64 [installed]
root@nfsclient:/#
root@nfsclient:/#
root@nfsclient:/# # Now mount, but does tries 4.2, fails, tries 4.1, fails then 4.0 and succeeds.
root@nfsclient:/#
root@nfsclient:/# mkdir iridio
root@nfsclient:/# mount -vvvv 192.168.3.81:/files/repos/sharedfolder iridio/
mount.nfs: timeout set for Tue May 4 10:55:35 2021
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.3.81,clientaddr=172.17.0.10'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.1,addr=192.168.3.81,clientaddr=172.17.0.10'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.0,addr=192.168.3.81,clientaddr=172.17.0.10'
root@nfsclient:/# echo $?
0
root@nfsclient:/#
The kernel in the docker is 4.19. In fact the docker engine is running on an Ubuntu 20.04 on an WSL-2 on a Windows 10 pro:
root@nfsclient:/# uname -a
Linux nfsclient 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@nfsclient:/#
Question
- Why two
ubuntu:20.04
, both with the very exact version ofnfs-common/focal-updates,focal-security,now 1:1.3.4-2.5ubuntu3.3 amd64
behave in such a way that one connects to the server viav4.2
and the other viav4.0
? - Does the version depend on the kernel I have?
- I see there's a thing it says "invalid argument" when trying the versions
v4.2
andv4.1
. Should I pass any extra option to be able to connect viav4.2
?
Solution 1:
The answer is in the question...
The modern versions of nfs utils will always try to use the highest nfs version by default, which is 4.2 as of today.
But, mount command itself is not a nfs client. Thus it forwards the mount request to the kernel. Depending on the kernel version and build time options different kernels can support different nfs versions. As the result, in some cases 4.2 is used right away and in another case kernel simply says "not supported" and let mout command to try again with a different nfs version.