4

I am running nfs4 only on both server and client. I am not sure what I changed recently, but I can no longer mount an exported file system which I used to be able to mount. I have just upgraded the client machine from Fedora 31 to 32... but I swear nfs was still working immediately after the upgrade.

At the client end I do:

  # mount /foo
  mount.nfs4: Protocol not supported

The /etc/fstab has not been changed. There is nothing already mounted at /foo. I get the same result issuing mount.nfs4 by hand.

Using wireshark at the client I can see absolutely nothing being sent to the nfs server (or being received from same). Using tcpdump I can see nothing at the server end, from before the client is rebooted to after the attempts to mount. So I'm guessing this is a client issue ?

I can see nothing in the logs. I have failed to find anything to wind up the logging level for client-side mounting.

Can anyone point me at ways to discover what the client is doing (or not doing) ?

As requested...

dmesg mentions of nfs|NFS:

[    7.987799] systemd[1]: Starting Preprocess NFS configuration convertion...
[    7.993220] systemd[1]: nfs-convert.service: Succeeded.
[    7.993342] systemd[1]: Finished Preprocess NFS configuration convertion.
[   12.484481] RPC: Registered tcp NFSv4.1 backchannel transport module.

And fstab on the client:

foo:/ /foo nfs4 noauto,sec=sys,proto=tcp,clientaddr=xx.xx.xx.xx,port=1001  0 0

The client has more than one IP. The server wishes to obscure the fact that it offers nfs. To make that easier it does nfs4 only. FWIW netstat on the server gives (edited for clarity):

Prot  R-Q S-Q  Local Address      Foreign Address  State    PID/Program
tcp    0   0   xx.xx.xx.xx:1001   0.0.0.0:*        LISTEN   -
tcp    0   0   0.0.0.0:111        0.0.0.0:*        LISTEN   1/systemd
tcp    0   0   0.0.0.0:1002       0.0.0.0:*        LISTEN   815/rpc.statd

I thought nfs4 required just the one port... but systemd seems to wake up port 111 anyway. There is also rpc.statd.

The configuration of the server used to work... Also, the client is not sending anything to the server at all on any port !

And the exports on the server:

/ bar(fsid=0,no_subtree_check,sec=sys,rw,no_root_squash,insecure,crossmnt)

Where bar is in the server's \etc\hosts file.

I did showmount -e foo on the client:

clnt_create: RPC: Program not registered

Wireshark tells me that the client poked the server on port 111 asking for MOUNT (100005) Version 3 tcp and received 'no' response. The poke for udp received the same answer. Since the server is configured nfs4 only, I guess this is not a surprise ? I note that showmount does not ask for Version 4... but I don't know if you'd expect it to ?

Chris Hall
  • 191
  • 1
  • 1
  • 7
  • Check for anything interesting in `dmesg`. – Michael Hampton Sep 10 '20 at 17:56
  • Can you add the exact entry from the fstab – kofemann Sep 10 '20 at 21:05
  • And while you're at it: `/etc/exports` from the server and the output of `showmount -e ` when run on the client. – Andreas Rogge Sep 10 '20 at 22:42
  • Thank you... I've updated the question. – Chris Hall Sep 11 '20 at 09:29
  • 111 is not needed for nfs4, you can remove `rpcbind`. Probably it'll help troubleshoot. Something that worries me is that port 2049, the default for nfs4 does not seem to be there on your server. Can you post the output of `sudo ss -tulp` command? – Krackout Sep 11 '20 at 10:34
  • I would be disappointed if port 2049 were open, since I am deliberately configuring the server on 1001 only (and that used to work !). Also, the client is not trying to reach port 2049 at any time, not even when the client boots. Nor is it trying to reach port 1001 (the configured port for nfs4, tcp). Nor is it trying to reach port 111. `mount.nfs4` on the client simply refuses to do anything at all, and I cannot see why :-( Is there some module that should be loaded ? I have done `modprobe nfs`. I have nfs and nfs4 in `/proc/filesystems`. – Chris Hall Sep 11 '20 at 11:31

1 Answers1

5

OK... so I downloaded the source and started poking around with strace.

The problem was that I had been over-enthusiastic in /etc/nfsmount.conf, specifically:

  1. for nfs4 it is a mistake to set any of these:

     mounthost
 mountaddr 
 mountvers
 mountproto

    in /etc/nfsmount.conf to anything at all (that includes setting mountvers=4 and setting mountproto=tcp).

    If (like me) you are stupid enough to do this, the code sets errno=EPROTONOSUPPORT and returns an error... as if socket() had failed. [The error reporting mechanics don't seem to be aware of this, and reports the error in a 'default' manner, using strerror().]

  2. it is also a mistake to set mounvers in /etc/nfsmount.conf.

    Again, if (like me) you are stupid enough misspell mountvers and put mounvers=4 in /etc/nfsmount.conf, you will get:

    # mount.nfs4 -v -o noauto,sec=sys,proto=tcp,port=1001 foo:/ /foo
mount.nfs4: timeout set for Fri Sep 11 16:24:09 2020
mount.nfs4: trying text-based options 'sec=sys,proto=tcp,port=1001,mounvers=4,vers=4.2,addr=xx,clientaddr=xx'
mount.nfs4: mount(2): Invalid argument
....

    ...which is I guess to be expected.

Ah well, I had nothing better to do for a couple of days :-(

Chris Hall
  • 191
  • 1
  • 1
  • 7