The NFSv4 client sends a port to the server for delegation callbacks. The server attempts to open a connection to the client on this port. By default, this port is ephemeral, and will be blocked if the client is running a firewall. However, rather than silently disabling delegation, the server continues to send SYN packets repeatedly, without pause, to the client. If rejected packets are being logged on the client, this can cause a massive log file output, filling up the filesystem. The workaround is to set the client delegation port to a fixed value "sysctl -w fs.nfs.nfs_callback_tcpport=4005", and then open that port in the client firewall. However, the server should not be NFS server version: # uname -a Linux edison 3.13.5-200.fc20.x86_64 #1 SMP Mon Feb 24 16:51:35 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux NFS client version: # uname -a Linux darwin 3.13.5-101.fc19.x86_64 #1 SMP Tue Feb 25 21:25:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux How reproducible: 100% of the time. Simply start a firewall on the client blocking ephemeral ports using iptables. Now mount an NFS export from the server. Use tcpdump to confirm that the server is sending SYN packets repeatedly. Expected results: A log message that callback delegation has been disabled due to port xxx being unreachable. Wait x seconds or minutes between further attempts, or simply disable delegation.
Also: the sysctl does not become available until *after* the mount has been created, which causes the firewall flood. So one has to shut down the firewall, mount, unmount, restart the firewall, set the sysctl, then mount again. As mentioned in bug #1076255, forcing NFS to version 4.1 works around the problem, as in NFS 4.1 the client creates the callback channel, and so the callback port is no longer necessary. Mount options: -tnfs4 -ominorversion=1 But I'm not sure why 4.1 needs to be forced anyway, it *seems* like it should be enabled by default, on kernel 3.13.5, but it isn't: # cat /proc/fs/nfsd/versions -2 +3 +4 +4.1 -4.2
(In reply to Raman Gupta from comment #1) > Mount options: > > -tnfs4 -ominorversion=1 > > But I'm not sure why 4.1 needs to be forced anyway, it *seems* like it > should be enabled by default, on kernel 3.13.5, but it isn't: > > # cat /proc/fs/nfsd/versions > -2 +3 +4 +4.1 -4.2 Note the "nfsd" in that path--this just says that the server will offer 4.1, not that the client will try to use it by default.
Right, plus NFS version negotiation is handled by the userland mount helper (mount.nfs). If you want to change what version gets negotiated by default that's where it has to be done. FWIW, it probably is time to move the default to 4.1...
(In reply to J. Bruce Fields from comment #2) > (In reply to Raman Gupta from comment #1) > > # cat /proc/fs/nfsd/versions > > -2 +3 +4 +4.1 -4.2 > > Note the "nfsd" in that path--this just says that the server will offer 4.1, > not that the client will try to use it by default. Good information, thanks. Yes, I think it makes sense to use 4.1 as a default, perhaps on Fedora 21. However, I believe the underlying problem described here when using 4.0 is severe enough to merit a maintenance fix.
(In reply to Jeff Layton from comment #3) > Right, plus NFS version negotiation is handled by the userland mount helper > (mount.nfs). If you want to change what version gets negotiated by default > that's where it has to be done. > > FWIW, it probably is time to move the default to 4.1... FYI, created #1080696.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.