mount.nfs: sloppy options processing is broken on 5.15 HWE kernel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
nfs-utils (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Medium
|
Matthew Ruffell |
Bug Description
[Impact]
There was a new mount API introduced to the nfs subsystem in the 5.6 kernel release, that changed how parameters should be passed from userspace mount.nfs to the kernel.
This broke processing of the sloppy '-s' and '-o' options, where if you have an invalid mount option, or the ordering of mount options was incorrect, the mount would fail instead of going through.
The fix is to move the sloppy options to the front of the options list, and then passing the rest of the options to the kernel, so the sloppy operator can be parsed correctly.
[Testcase]
Start two Focal VMs, one for the server, and one for the client.
On the Server:
1) sudo apt update
2) sudo apt install nfs-kernel-server
3) sudo mkdir -p /mnt/nfs_share
4) sudo chown -R nobody:nogroup /mnt/nfs_share/
5) sudo chmod 777 /mnt/nfs_share/
6) echo "/mnt/nfs_share 192.168.
7) sudo exportfs -a
8) sudo systemctl restart nfs-kernel-server
9) echo "Testfile" | tee /mnt/nfs_
On the client:
1) sudo apt update
2) sudo apt install nfs-common
3) sudo mkdir -p /mnt/nfs_
4) sudo mount -t nfs 192.168.
On the client with 5.4 kernel:
$ uname -rv
5.4.0-152-generic #169-Ubuntu SMP Tue Jun 6 22:23:09 UTC 2023
$ sudo mount -t nfs 192.168.
$ cd /mnt/nfs_
/mnt/nfs_
total 12
drwxrwxrwx 2 nobody nogroup 4096 Jun 29 01:13 ./
drwxr-xr-x 3 root root 4096 Jun 29 01:11 ../
-rw-rw-r-- 1 ubuntu ubuntu 9 Jun 29 01:13 testfile
/mnt/nfs_
Testfile
On the client with the 5.15 HWE kernel:
$ uname -rv
5.15.0-76-generic #83~20.04.1-Ubuntu SMP Wed Jun 21 20:23:31 UTC 2023
$ sudo mount -t nfs 192.168.
mount.nfs: an incorrect mount option was specified
There are test packages in the following ppa:
https:/
If you install them, when using the HWE kernel, you will see:
$ uname -rv
5.15.0-76-generic #83~20.04.1-Ubuntu SMP Wed Jun 21 20:23:31 UTC 2023
$ sudo mount -t nfs 192.168.
$ cd /mnt/nfs_
/mnt/nfs_
total 12
drwxrwxrwx 2 nobody nogroup 4096 Jun 29 01:13 ./
drwxr-xr-x 3 root root 4096 Jun 29 01:11 ../
-rw-rw-r-- 1 ubuntu ubuntu 9 Jun 29 01:13 testfile
/mnt/nfs_
Testfile
[Where problems could occur]
We are changing how options parameters are parsed. If a regression were to occur, user's nfs mount commands might fail, which has the possibility of breaking nfs-clients. If a system is set to mount a share on boot, a share might not be available without manual intervention.
Users should not have to modify their mount commands at all. But if a regression were to occur, sysadmins may need to change to the ordering of their options.
This does not change nfs-servers, only nfs-clients.
[Other Info]
This issue was fixed in 2.6.1 of nfs-utils with the following commits:
commit 92b664ef4f25f1b
From: Jianhong Yin <yin-jianhong@
Date: Thu, 10 Jun 2021 13:27:29 -0400
Subject: mount.nfs: insert 'sloppy' at beginning of the options
Link: https:/
commit 4dd8d833c9350d4
From: Steve Dickson <email address hidden>
Date: Tue, 20 Jul 2021 17:14:04 -0400
Subject: mount.nfs: Fix the sloppy option processing
Link: https:/
Changed in nfs-utils (Ubuntu): | |
status: | New → Fix Released |
Changed in nfs-utils (Ubuntu Focal): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Matthew Ruffell (mruffell) |
tags: | added: sts |
tags: |
added: se-sponsor-halves removed: sts |
Attached is a debdiff for focal that solves this issue.