Major issues with nfsv4

[Rick Macklem]

J. David wrote:
>Ah, oops.  The "12.2 servers" referred to at the top of the message
>are the NFS *clients* in this scenario.  They are application servers,
>not NFS servers.  Sorry for the confusing overloaded usage of "server"
>there!
So what is your NFS server running?

Btw, if it happens to be a Linux system and you aren't using Kerberos,
it will expect Users/Groups as the numbers in strings by default.
To do that, do not start the nfsuserd(8) daemon on the client and
instead add the following line to the client's /etc/sysctl.conf file:
vfs.nfs.enable_uidtostring=1

When User/Group mapping is broken, you'll see lots of files owned
by "nobody".

Also, if you do want to see what the NFS packets look like, you can
capture packets with tcpdump, but then look at them in wireshark.
# tcpdump -s 0 -w out.pcap host <nfs-server>
- then look at out.pcap in wireshark. Unlike tcpdump, wireshark
  knows how to parse NFS messages properly.

rick
ps: Once you have switched to NFSv4.1 and have User/Group
     mapping working, I suspect the NFS clients will be ok.
     Using NFSv4.1 also avoids FreeBSD NFS server issues w.r.t.
     tuning the DRC, since it is not used by NFSv4.1 (again, fixed
     by sessions).

Everything in the message (dmesg, tcpdump, nfsstat, etc.) is from the
perspective of a FreeBSD 12.2 NFS client, which is where the problems
are occurring.

Our Linux servers (machines? instances? hosts? nodes?) that are NFS
clients have been running NFSv4 against the same servers for many
years without incident.

Thanks!
_______________________________________________
freebsd-fs at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"