mount.nfs: fix version negotiation laddering with parameters '-t nfs4' or '-o vers=4'
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
nfs-utils (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Medium
|
Matthew Ruffell |
Bug Description
[Impact]
Calling mount.nfs with parameters '-t nfs4' or '-o vers=4' will default to attempting to connect with version 4.0 only, and if the server does not support 4.0, the mount will fail.
The expected behaviour is first default to negotiating version 4.2, and if that fails, then 4.1, and then 4.0, before raising an error.
This laddering approach was specified and agreed upon in:
commit f980298853d9b12
Author: Benjamin Coddington <email address hidden>
Date: Mon Dec 8 15:51:07 2014 -0500
Subject: mount.nfs: configurable minor version defaults
Link: https:/
first introduced in nfs-utils in 2014, in version 1.3.2-rc6, and is included in the version offered in focal.
This behaviour works when you don't specify a version at all, or even specify nfs at all to the mount command.
A graphical explanation of the laddering approach is:
---
| nfsmount.conf |------
| Defaultvers= | arg option | attempts: |
|--
| 4.2 | not set | v4.2 v4.1 v4.0 v3 |
| 4.2 | v4 | v4.2 v4.1 v4.0 |
| 4.1 | not set | v4.1 v4.0 v3 |
| 4.1 | v4 | v4.1 v4.0 |
| 4 | not set | v4.0 v3 |
| 4 | v4 | v4.0 |
| 3 | not set | v3 |
| any set | v4.2 | v4.2 |
| any set | v4.1 | v4.1 |
| any set | v4 | v4.0 |
| any set | v3 | v3 |
| not set | not set | v4.2 v4.1 v4.0 v3 |
---
This should also apply to using the command line arguments '-t nfs4' or '-o vers=4' matching existing and current upstream designs.
[Testcase]
Create two VMs, one jammy and one focal.
The jammy VM will be the server.
Server VM:
$ sudo hostnamectl set-hostname jammy-nfs-server
$ sudo apt update && sudo apt upgrade -y
$ sudo apt install nfs-kernel-server
$ sudo mkdir /export
$ sudo mkdir /export/users
$ sudo mkdir /home/users
$ sudo vi /etc/fstab # add the following line:
/home/users /export/users none bind 0 0
$ sudo mount -a
$ sudo vi /etc/exports # add the following lines:
/export 192.168.
/export/users 192.168.
$ sudo vi /etc/nfs.conf # Under [nfsd], uncomment / change the following lines:
vers2=n
vers3=n
#vers4=y
vers4.0=n
vers4.1=y
vers4.2=y
$ sudo systemctl restart nfs-server.service
$ sudo cat /proc/fs/
-2 -3 +4 -4.0 +4.1 +4.2
Focal VM:
$ sudo hostnamectl set-hostname focal-nfs-client
$ sudo apt update && sudo apt upgrade -y
$ sudo apt install nfs-common
And then try to mount using '-o vers=4':
$ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt
You will see:
$ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt
mount.nfs: timeout set for Fri Jan 19 00:44:42 2024
mount.nfs: trying text-based options 'vers=4,
mount.nfs: mount(2): Protocol not supported
mount.nfs: Protocol not supported
Test packages are available in the following ppa:
https:/
If you install the test package, you will see:
$ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt
mount.nfs: timeout set for Fri Jan 19 00:46:09 2024
mount.nfs: trying text-based options 'vers=4.
$ ll /mnt
total 12
drwxr-xr-x 3 root root 4096 Jan 17 22:30 ./
drwxr-xr-x 19 root root 4096 Jan 19 00:41 ../
drwxr-xr-x 2 root root 4096 Jan 17 22:30 users/
If you disable v4.2 on the jammy nfs server VM, and try and reconnect, we see
the laddering to 4.1:
$ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt
mount.nfs: timeout set for Fri Jan 19 00:53:43 2024
mount.nfs: trying text-based options 'vers=4.
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'vers=4.
:~$ ll /mnt
total 12
drwxr-xr-x 3 root root 4096 Jan 17 22:30 ./
drwxr-xr-x 19 root root 4096 Jan 19 00:41 ../
drwxr-xr-x 2 root root 4096 Jan 17 22:30 users/
[Where problems could occur]
We are changing the default protocol negotiation code for mount.nfs, so specifying '-t nfs4' or '-o vers=4' will no longer default to 4.0, instead, it will now attempt 4.2, 4.1, 4.0 in a laddering fashion. This may cause a different NFS version to be selected on mount, if the fstab or shell scripts system administers use '-t nfs4' or '-o vers=4' instead of specifying a specific version.
e.g. 4.2 may be selected instead of 4.0 used previously. This could have an impact on workloads if there are any regressions in switching to 4.2 from 4.0 etc. Network traffic may be different as newer protocols are used.
The dependency commit "mount.nfs: improve version negotiation when vers=4 is specified." also fixed a few bugs, with the most impactful being that in some cases mount.nfs would downgrade from v4 to v3, even when v4 was explicity asked for, if a particular namespace was available in v3, but not in v4, e.g. by fsid=0.
If a regression were to occur, users could have trouble mounting NFS v4.x shares as a client.
NFS server has no changes.
[Other info]
This was fixed in nfs-utils 2.1.2-rc4 by the following commits:
commit d406648690fa0fd
Author: NeilBrown <email address hidden>
Date: Thu Jun 1 09:42:16 2017 -0400
Subject: mount.nfs: improve version negotiation when vers=4 is specified.
Link: https:/
commit 62a4d95854e5cda
Author: Steve Dickson <email address hidden>
Date: Tue Jun 13 12:00:39 2017 -0400
Subject: mount.nfs: Use default minor version when -t nfs4 is specified
Link: https:/
commit 90790d3129cf6f5
Author: Steve Dickson <email address hidden>
Date: Mon Jun 19 11:19:55 2017 -0400
Subject: mount.nfs: Use default minor version when -o v4 is specified
Link: https:/
These are found in Jammy and later.
affects: | pulseaudio (Ubuntu) → nfs-utils (Ubuntu) |
Changed in nfs-utils (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in nfs-utils (Ubuntu Focal): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Matthew Ruffell (mruffell) |
tags: | added: focal sts |
tags: | added: sts-sponsor |
Status changed to 'Confirmed' because the bug affects multiple users.