Home / ubuntu / Questions / 1526070
Accepted
John Rennie
Asked: 2024-09-08 17:52:49 +0800 CST

Checking why an NFS mount gives an error

  • 772

I'm asking on behalf of a friend's son who is at college in India, so apologies if what I ask doesn't have enough information. He is using WSL2 on Windows 11 and has Ubuntu 22.04.3 LTS installed.

His prof has given these instructions for mounting an NFS share needed for the course:

sudo apt-get install nfs-common
cd /
sudo mkdir tools
sudo mount -t nfs 10.0.17.82:/tools /tools

The first three commands work fine but the mount fails. I got him to add a -v flag and the output is:

minor@Tejas:~$ sudo mkdir /tools
[sudo] password for minor:
minor@Tejas:~$ ls /tools
minor@Tejas:~$ sudo mount -v -t nfs 10.0.17.82:/tools /tools
mount.nfs: timeout set for Sun Sep  8 15:10:40 2024
mount.nfs: trying text-based options 'vers=4.2,addr=10.0.17.82,clientaddr=172.29.144.144'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=10.0.17.82,clientaddr=172.29.144.144'
mount.nfs: mount(2): Operation not permitted
mount.nfs: trying text-based options 'addr=10.0.17.82'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.17.82 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.0.17.82 prog 100005 vers 3 prot UDP port 20048
mount.nfs: mount(2): Permission denied
mount.nfs: Operation not permitted
minor@Tejas:~$

I asked him to use showmount and the result was:

minor@Tejas:~$ showmount -e 10.0.17.82
Export list for 10.0.17.82:
/ *

I can't see a /tools export in the list, but then I don't know if I should be able to see it. It's entirely possible his prof has not configured the server properly.

Anyhow can anyone suggest what is wrong, or further steps to check what the problem is?

22.04

1 Answers

  1. Best Answer

    It's hard to make a definitive diagnosis without seeing the server-side NFS logs1, however the behavior might be explained by the fact that the WSL network interface uses Network Address Translation (NAT) which causes the client-side source port to appear to be non-privileged, while the server exports the remote filesystem using the secure option - which only permits connections from privileged ports.

    To demonstrate, I configured nfs-kernel-server on a Kubuntu 24.04 box with the following /etc/exports file:

    /               192.168.1.0/24(rw,nohide,secure,no_subtree_check,sync)

    and created a /tools directory with a dummy /tools/sometool file, then tried to mount it from a VirtualBox VM running Ubuntu 22.04 with a NAT interface:

    • Host (Windows) IP: 192.168.1.9

    • Guest (Ubuntu 22.04) IP: 10.0.2.15 (NAT)

        $ sudo mount -t nfs -vvv 192.168.1.26:/tools /tools
  mount.nfs: timeout set for Mon Sep  9 17:33:09 2024
  mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.26,clientaddr=10.0.2.15'
  mount.nfs: mount(2): Operation not permitted
  mount.nfs: trying text-based options 'addr=192.168.1.26'
  mount.nfs: prog 100003, trying vers=3, prot=6
  mount.nfs: trying 192.168.1.26 prog 100003 vers 3 prot TCP port 2049
  mount.nfs: prog 100005, trying vers=3, prot=17
  mount.nfs: trying 192.168.1.26 prog 100005 vers 3 prot UDP port 43961
  mount.nfs: mount(2): Permission denied
  mount.nfs: Operation not permitted

    • Server-side log:

       Sep 09 13:31:09 htpc rpc.mountd[457645]: refused mount request from 192.168.1.9 for /tools (/): illegal port 58242

    Note the high-numbered (>1024) source port in the error message illegal port 58242.

    Re-configuring the VM interface in bridged mode:

    • Host (Windows) IP: 192.168.1.9

    • Guest (Ubuntu 22.04) IP: 192.168.1.22 (BRIDGED)

        $ sudo mount -t nfs -vvv 192.168.1.26:/tools /tools
  mount.nfs: timeout set for Mon Sep  9 17:38:28 2024
  mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.26,clientaddr=192.168.1.22'
  $ 
  $ ls /tools
  sometool

    Server-side log:

        Sep 09 13:36:28 htpc rpc.mountd[457645]: auth_unix_ip: inbuf 'nfsd 192.168.1.22'
    Sep 09 13:36:28 htpc rpc.mountd[457645]: successful authentication for IP 192.168.1.22 as 192.168.1.0/24
    Sep 09 13:36:28 htpc rpc.mountd[457645]: auth_unix_ip: client 0x5d0dce71bef0 '192.168.1.0/24'

    For further evidence that it's the non-privileged port that's the problem, I then tried adding the noresvport option to the mount command on the bridged VM:

        sudo mount -t nfs -onoresvport -vvv 192.168.1.26:/tools /tools

    and got the same behaviour as for the NAT configuration.

    Some possible workarounds are:

    1. It may be possible to configure WSL to use a bridged interface, as described in this blog for example How to brigde [sic] Windows Subsystem for Linux

      However that's outside the scope of this site.

    2. You could switch to a "bare metal" Ubuntu installation, or a virtualization solution that permits bridged interfacing out of the box like Oracle Virtualbox or VMware.

    3. You could ask your prof to modify the export to permit non-privileged port numbers - if it's a modern Linux based server, that would mean adding the insecure option (or changing secure to insecure):

       secure This option requires that requests not using gss originate on an
          Internet  port  less than IPPORT_RESERVED (1024). This option is
          on by default.  To turn it off, specify insecure.

    For further information see

    If the prof's server is running a systemd-based Linux then logging isn't enabled by default, but may be enabled by following the instructions here Where are NFS v4 logs under systemd?

    • 1