unable to mount nfs on Ubuntu 22.04

I've installed Ubuntu 22.04 on a machine and I am trying to mount an NFS share which has no problems mounting on an array of other Linux Ubuntu machines (21.04, 20.04, 18.04, etc.).

The command we use is:

sudo apt install nfs-common # Only required once for installation
sudo mount -t nfs 10.234.123.11:/bfx_share1 /bfx_share1

If I do a:

sudo showmount -e 10.234.123.11

It shows the list of possible mounts, so everything is kosher in that respect.

It's just stuck there, not doing anything. Any ideas? Anything I can do or add to debug the situation? Any other clients not nfs-common?

I've installed nfstrace and while trying to mount the nfs folder, I kicked it off in another terminal, to obtain the prompt below:

## On one terminal
(base) user@LS6-MS-7D04:~$ ping 10.234.123.11
PING 10.234.123.11 (10.234.123.11) 56(84) bytes of data.
64 bytes from 10.234.123.11: icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 10.234.123.11: icmp_seq=2 ttl=64 time=0.122 ms
64 bytes from 10.234.123.11: icmp_seq=3 ttl=64 time=0.172 ms
^C
--- 10.234.123.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2027ms
rtt min/avg/max/mdev = 0.122/0.165/0.202/0.033 ms
(base) user@LS6-MS-7D04:~$ sudo mount 10.234.123.11:/bfx_share1 /bfx_share1
## In the other terminal with nfstrace running
root@LS6-MS-7D04:/home/user# nfstrace -Z user
Log file: nfstrace.log
Read from interface: enp111s0 BPF filter : port 2049 or port 445 snapshot len: 65535 bytes read timeout: 100 ms buffer size : 20971520 bytes promiscuous mode: on capture traffic : inout
Processing packets. Press CTRL-C to quit and view results.
Detect session 10.234.123.8:902 --> 10.234.123.11:2049 [TCP]
Detect session 10.234.123.8:772 --> 10.234.123.11:2049 [TCP]
10.234.123.8:772 --> 10.234.123.11:2049 [TCP]NULL CALL [] REPLY []
Detect session 10.234.123.8:947 --> 10.234.123.11:2049 [TCP]
10.234.123.8:947 --> 10.234.123.11:2049 [TCP]NULL CALL [] REPLY []

Looking at the release notes of Ubuntu 22.04 (Jammy Jellyfish Release Notes):

There is a section:

UDP disabled for NFS mounts
Since Ubuntu 20.10 (“Groovy Gorilla”), the kernel option CONFIG_NFS_DISABLE_UDP_SUPPORT=y is set and this disables using UDP as the transport for NFS mounts, regardless of NFS version.
In practice, if you try to use udp, you will get this error:
$ sudo mount f1:/storage /mnt -o udp
mount.nfs: an incorrect mount option was specified
###
NFS server
The NFS server and client packages have finally been updated to the latest upstream version.
All NFS services now read their configuration from /etc/nfs.conf and /etc/nfs.conf.d/*.conf, which is an INI-style configuration file, where each section is about one daemon or aspect of the NFS service. The old /etc/defaults/nfs-* configuration files are still left around, but are unused.
During upgrade, a conversion script is run if the package detects that the /etc/default/nfs-* files have been changed. This script is /usr/share/nfs-common/nfsconvert.py and it will read the options from /etc/defaults/nfs-* and generate /etc/nfs.conf.d/local.conf, which overrides the defaults in /etc/nfs.conf.
If the conversion script fails for some reason, the package installation or upgrade will fail, and the issue will have to be resolved. Please file a bug against nfs-utils in Launchpad 2 if you encounter such a scenario.
A new tool called nfsconf(8) can be used to query the configuration settings of /etc/nfs.conf and /etc/nfs.conf.d/*.conf.
##
the CTDB package was adjusted to work with the new NFS server version shipped in this Ubuntu 22.04

I've submitted a bug report in:

6 Answers

While I am not entirely sure of the reason for this, I found that adding mountvers=3 to the mount options resolved the hanging problem.

so

mount -t nfs -o mountvers=3 <server_ip>:/path/to/shared-folder /path/to/local/mount

resulted in a correct mount.

My interpretation is that if multiple versions of NFS server (e.g. 3 and 4) are running on the same server, the mountvers will help use the right version.

Had same issue, used this solution to get fstab working ...

192.168.1.10:/foo /home/john/foo nfs4 auto,vers=3 0 0

mountvers=4.0 works as well for me

apparently the issue is with it defaulting to 4.2 according to

I experienced the same issue. I only had an NFS4 server and the mount commands would hang. I enabled NFS3 on the NAS end and used the solution provided here and they seem to work now. So I think the issue is with version 4 mounts

For the uninitiated folks, it appears the nfs-common for Ubuntu 22.04 changed "nfsvers" option to "mountvers"

sudo mount -t nfs -o mountvers=4 [server IP]:/remote/path /local/mount/path

Note: both mountvers=3 and mountvers=4 works for my QNAP NAS server.

I can also confirm what other have already posted. On Ubuntu 22.04 the nfsvers option needs to be replaced with mountvers.

But this was still not working for after I migrated from 20.04 LTS to 22.04 LTS together with my QNAP v4.3.6.1965, where it worked before just fine with NFS4.

I've checked multiple stackoverflow/askubuntu/etc. threads and nothing worked after the Ubuntu upgrade. But here is what actually worked for me (haven't figured out the root causes yet):

1. Use mountvers=4.0 instead of nfsvers as option to in /etc/fstab or your mount call
2. Even though using mountvers=4.0 only NFS3 ended up being used during mount and the only thing to really work. So (unfortunately) make sure to also enable NFS3 in your QNAP's NFS settings.
3. If you still get a mount.nfs: mount(2): Permission denied reply from QNAP, then adapt any hostnames in your QNAP's NFS host access settings to IP addresses!

Especially the last point about the hostnames vs. IP addresses was the biggest blocker here! I don't know why that is needed now, because it worked fine with hostnames on Ubuntu 22.04 and the machine still has the same hostname properly configured.

Hope this helps others as well.