2

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): https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668?_ga=2.137381111.630065420.1651222708-2033241278.1650531954

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: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1970898

4
  • have you installed nfs-common I guess the procedure is similar for 22.04 LTS
    – 24601
    Apr 28 at 11:54
  • Does showmount -e 10.234.123.11 work? if not, does it eventually time out? Apr 28 at 13:23
  • showmount -e 10.234.123.11 does work and shows what should show. But the mounting stays stuck forever (several hours so far).
    – 719016
    Apr 28 at 14:47
  • 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
    – Matt
    May 1 at 19:05

5 Answers 5

2

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.

2
  • This solved the problem for us, thanks! If you leave a way to contact, I'd like to send you a t-shirt for free to thank you for your help!
    – 719016
    May 3 at 8:51
  • Didn't solve it for me, unfortunately. Nov 4 at 14:50
2

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

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

mountvers=4.0 works as well for me

apparently the issue is with it defaulting to 4.2 according to https://ubuntuforums.org/showthread.php?t=2474184

0

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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.