Basic NFSv4 / Cannot Mount / Firewall Problem?

Rocky Linux General
1

Just setup my new Rocky server and after adding NFS exports I cannot mount them from a client that happily mounted these exports on the previous server.

# mount -t nfs4 rocky.soho.lan:/disk3/stuff /mnt
mount.nfs4: No route to host
# ping rocky.soho.lan
PING rocky.soho.lan (10.11.12.13) 56(84) bytes of data.
64 bytes from rocky.soho.lan (10.11.12.13): icmp_seq=1 ttl=64 time=0.372 ms
64 bytes from rocky.soho.lan (10.11.12.13): icmp_seq=2 ttl=64 time=0.335 ms

Is there an NFS log file?

How does one go about debugging NFS?

Got a WireShark capture and it shows the client requests are going completely unanswered. This might suggest a firewall is involved but the RedHat 8 documentation section 4.8 Installing NFS doesn’t say anything about a firewall. There is discussion about firewalls but in ways that seem to be unrelated to NFSv4 (such as wrt rpcbind which I get the impression is specific to NFSv3).

I’m guessing there is some command that I have to run to add firewall rules for NFSv4 but I’m struggling to find something about it in the RedHat docs.

Ideas?

Mike

UPDATE:

For posterity, this appears to be the basic minimal NFSv4-only procedure:

# vi /etc/exports:
/disk3/stuff *(rw)
# exportfs -rav
# systemctl enable --now nfs-server
# firewall-cmd --permanent --add-service nfs
# firewall-cmd --reload
2 Likes
2

“No route to host…” means the firewall is blocking. On the server running nfs, you need to add firewall rules to allow.

3

Hello ioplex,

did you ever get passed this problem?

I seem to have the same problem on Rocky 8.7,
attempting to implement a NFSv4/tcp only server.

Problem: it will never connect, if the initial attempt after a {NFS-client host | NFS-server host | nfs-service restart} is done as NFSv4.
Instead it gets stuck at the second line of the mount output (“mount.nfs4: trying text-based options …”) - waiting forever.
No logging, no activity, nothing…
But: NFSv3 works.

My debugging attempts:

  1. disabling SELinux,
  2. switching off firewall,
  3. relaxing permissions on share and in exports conf to the max

but nothing of this helped.

The strange thing here:

  1. pings always worked at the same time, and
  2. telnet to 2048 also worked perfectly fine as well!

So definitely not a network issue for me.

After one day of debugging it turned out for me that the following ALWAYS works:

  1. Start the initial (after NFS client host or NFS server host had rebooted) NFS connection using NFSv3.
  2. Then disconnect NFSv3 and reconnect as NFSv4 (4.0-4.2 are all fine in the same way).

Works always for me.

This procedure only has to be repeated if one of both the servers (or the nfs-server daemon) has been restarted.

Unfortunately, logging in NFS is a night…ly thing.
Toggling the “debug” flag in nfs.conf always causes “Invalid debug facility: 1” for me, but no logging still… If i am right, it takes tracing and tcpdump to dig deeper.

Does my observation rings a bell for anyone, which would help to track down the actual problem?
I would highly appreciate this!
Because i have to implement this for nodes which have to be mass deployed in an automatic fashion.
And locking down to 2049 and tcp is one of the major benefits for me, but also performance.

5

Hello,

ammending my previous post: in the meantime i found out that no matter how restrictive i attempt to lock NFS to v4, the mount client will apparentl ALWAYS keep starting the server conenction via rpc.
This keeps stalling, with the following logs:

Apr 25 15:58:23 host kernel: RPC:       xs_close xprt 000000003938744e
Apr 25 15:58:23 host kernel: RPC:       xs_tcp_state_change client 000000003938744e...
Apr 25 15:58:23 host kernel: RPC:       state 4 conn 1 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:58:23 host kernel: RPC:       xs_tcp_state_change client 000000003938744e...
Apr 25 15:58:23 host kernel: RPC:       state 5 conn 0 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:58:23 host kernel: RPC:       xs_tcp_state_change client 000000003938744e...
Apr 25 15:58:23 host kernel: RPC:       state 7 conn 0 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:58:23 host kernel: RPC:       xs_tcp_state_change client 000000003938744e...
Apr 25 15:58:23 host kernel: RPC:       state 7 conn 0 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:58:23 host kernel: RPC:       xs_data_ready...


##start
## mount -vvv -t nfs4 -o proto=tcp,vers=4.2 10.10.0.2:/exports /mnt

Apr 25 15:58:50 host kernel: RPC:       set up xprt to 10.10.0.2 (port 2049) via tcp
Apr 25 15:58:50 host kernel: RPC:       Couldn't create auth handle (flavor 390004)
Apr 25 15:58:50 host kernel: RPC:       set up xprt to 10.10.0.2 (port 2049) via tcp
Apr 25 15:58:50 host kernel: RPC:       xs_connect scheduled xprt 0000000029b18705
Apr 25 15:58:50 host kernel: RPC:        destroy backchannel transport
Apr 25 15:58:50 host kernel: RPC:       xs_bind 0.0.0.0:694: ok (0)
Apr 25 15:58:50 host kernel: RPC:        backchannel list empty= true
Apr 25 15:58:50 host kernel: RPC:       xs_destroy xprt 0000000022615b26
Apr 25 15:58:50 host kernel: RPC:       xs_close xprt 0000000022615b26
Apr 25 15:58:50 host kernel: RPC:       worker connecting xprt 0000000029b18705 via tcp to 10.10.0.2 (port 2049)
Apr 25 15:58:50 host kernel: RPC:       0000000029b18705 connect status 115 connected 0 sock state 2
Apr 25 15:58:50 host kernel: RPC:       xs_tcp_state_change client 0000000029b18705...
Apr 25 15:58:50 host kernel: RPC:       state 1 conn 0 dead 0 zapped 1 sk_shutdown 0
Apr 25 15:58:50 host kernel: RPC:       xs_tcp_send_request(40) = 0
Apr 25 15:58:50 host kernel: RPC:       xs_data_ready...
Apr 25 15:58:50 host kernel: RPC:       setup backchannel transport
Apr 25 15:58:50 host kernel: RPC:       adding req= 00000000d49b2b48
Apr 25 15:58:50 host kernel: RPC:       setup backchannel transport done
Apr 25 15:58:50 host kernel: svc: initialising pool 0 for NFSv4 callback
Apr 25 15:58:50 host kernel: svc: svc_destroy(NFSv4 callback, 2)
Apr 25 15:58:50 host kernel: RPC:       xs_tcp_send_request(244) = 0


## mount client waiting: mount.nfs4: trying text-based options 'proto=tcp,vers=4.2,hard,port=2049,sec=none,addr=10.10.0.2,clientaddr=10.10.0.3'

## CTRL'D
Apr 25 15:59:15 host kernel: RPC:        destroy backchannel transport
Apr 25 15:59:15 host kernel: RPC:        req=00000000d49b2b48
Apr 25 15:59:15 host kernel: RPC:        free allocations for req= 00000000d49b2b48
Apr 25 15:59:15 host kernel: RPC:        backchannel list empty= true
Apr 25 15:59:15 host kernel: svc: svc_destroy(NFSv4 callback, 2)
Apr 25 15:59:15 host kernel: svc: svc_destroy(NFSv4 callback, 1)
Apr 25 15:59:15 host kernel: RPC:        destroy backchannel transport
Apr 25 15:59:15 host kernel: RPC:        backchannel list empty= true
Apr 25 15:59:15 host kernel: RPC:       xs_destroy xprt 0000000029b18705
Apr 25 15:59:15 host kernel: RPC:       xs_close xprt 0000000029b18705
Apr 25 15:59:15 host kernel: RPC:       xs_tcp_state_change client 0000000029b18705...
Apr 25 15:59:15 host kernel: RPC:       state 4 conn 1 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:59:15 host kernel: RPC:       xs_tcp_state_change client 0000000029b18705...
Apr 25 15:59:15 host kernel: RPC:       state 5 conn 0 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:59:15 host kernel: RPC:       xs_tcp_state_change client 0000000029b18705...
Apr 25 15:59:15 host kernel: RPC:       state 7 conn 0 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:59:15 host kernel: RPC:       xs_tcp_state_change client 0000000029b18705...
Apr 25 15:59:15 host kernel: RPC:       state 7 conn 0 dead 0 zapped 1 sk_shutdown 3
Apr 25 15:59:15 host kernel: RPC:       xs_data_ready...
^C

with the following client config:

/etc/nfsmount.conf
[ NFSMount_Global_Options ]
Defaultvers=4
Nfsvers=4
Defaultproto=tcp
Proto=tcp
Hard=True
Port=2049
Sec=none

I would have expected to not pbserve any rpc activity in NFSv4 only implementation?
Best