0

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 of nfs-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 via v4.2 and the other via v4.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 and v4.1. Should I pass any extra option to be able to connect via v4.2?
kofemann
  • 4,626
  • 1
  • 25
  • 30
Xavi Montero
  • 355
  • 3
  • 18
  • 1
    I have removed the docker and virtualbox tags as they are neither a part of the question nor the answer – kofemann May 05 '21 at 08:05

1 Answers1

2

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.

kofemann
  • 4,626
  • 1
  • 25
  • 30
  • Thanks, @kofemann, is there any command to list the "nfs capabilities" of a running kernel to see this in action? – Xavi Montero May 04 '21 at 20:56
  • 2
    Some kernels compiled so that the configuration is available at * /proc/config.gz* file. There you can find which nfs options are enabled. – kofemann May 04 '21 at 21:02
  • Thanks for all. One of my kernels does have a `/proc/config.gs`. Precisely the one not supporting newer versions, I can see options like `CONFIG_NFS_V4=y` but also `# CONFIG_NFS_V4_1 is not set` so it was a disabled option. For the other kernel, there's no `/proc/config.gs` file. Any way to discover this info? – Xavi Montero May 04 '21 at 22:37
  • xref: https://serverfault.com/q/1062587/253400 – Xavi Montero May 04 '21 at 22:51