Description of problem: NFS4 unmount sends NFS3 mountd traffic Version-Release number of selected component (if applicable): nfs-utils-1.1.0-3.fc7 kernel-2.6.22.4-65.fc7 How reproducible: Have host with NFS4 root (fsid=0) share Steps to Reproduce: 1. red# mount -t nfs4 blue:/ /tmp/blue 2. red# umount -t nfs4 /tmp/blue 3. Profit (by way of nuisance error message) Actual results: Error message on blue (the server): Aug 31 03:05:21 blue mountd[2535]: refused unmount request from red for / (/): not exported Expected results: No error message, totally clean umount Additional info: I have packet traces from both machines if needed. It clearly sends: V3 UMNT Call / when unmounting an NFS4 mount. It did not do this until I booted into 2.6.22.4-65.fc7 on the client machine - and then very soon after and often as I have a cron job that uses a NFS4 autofs mount. Also see 269861 as I originally blamed this on autofs.
has this bug been looked at? it is still an open problem, even with the latest update - 2.6.22.5-76.fc7.
Hello David, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. The packet traces you mention might help - no harm in attaching as text/plain if you can. It might be helpful to test with the latest kernel as well. I'll then re-assign to the relevant maintainers. If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged.
Created attachment 215121 [details] Packet output of an unmount of an NFS4 mount note how it switches from V4 calls to using portmap and then sends an unmount request to rpc.mountd.
BTW that is close to the latest kernel (2.6.22.7-85.fc7)
Created attachment 215171 [details] Packet output of a manual mount/umount of a NFS4 share
latest kernel 2.6.22.9-91.fc7 also has the same problem
Hi David, I promised to re-assign this bug but didn't. Apologies. Please could you update to let me know if you are still experiencing this issue and I will then re-assign as per: http://fedoraproject.org/wiki/KernelBugTriage Thanks Chris
Yes, I still am: server: Linux blue 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 EST 2007 i686 athlon i386 GNU/Linux Jan 13 13:42:37 blue mountd[12371]: refused unmount request from green for / (/): not exported client: Linux green 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
Okay, thanks for the feedback David. Updating for F8 and re-assigning...
any movement on this? it still happens under 2.6.23.15-137.fc8 still. Thanks, -Dave
nfs-utils-1.1.1-1.fc8 has been submitted as an update for Fedora 8
Fixed in nfs-utils-1.1.1-1.fc8 which can be found at: http://koji.fedoraproject.org/koji/buildinfo?buildID=40990
nfs-utils-1.1.1-1.fc8 introduces a serious regression for me: (after installing nfs-utils and rebooting) [root@blue ~]# mount -t nfs4 blue:/ /mnt/anon1 <hangs forever> [root@blue ~]# mount blue:/ /mnt/anon1 <hangs forever> [root@green ~]# mount -t nfs4 blue:/ /mnt/anon1 <hangs forever> [root@green ~]# mount blue:/ /mnt/anon1 <hangs forever> then, to get it back... [root@blue ~]# rpm --nodeps -e nfs-utils && yum -y install nfs-utils && service nfs start [root@green ~]# mount -t nfs4 blue:/ /mnt/anon1/ && echo woot woot
wow.... I'm not seeing that... Could you please post a binary bzip2 tshark network trace? Something simlar to: tshark -w /tmp/bz270541.pcap host blue bzip2 /tmp/bz270541.pcap Also, what is the output of 'mount -v -t nfs4 blue:/ /mnt/anon1" and 'mount blue:/ /mnt/anon1' tia
nfs-utils-1.1.1-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nfs-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-2244
it looks like V3 hangs because mountd crashes: # mount.nfs localhost:/mnt/blue /mnt/anon4 -v mount.nfs: trying 127.0.0.1 prog 100003 vers 3 prot TCP port 2049 mount.nfs: trying 127.0.0.1 prog 100005 vers 3 prot UDP port 34010 mount.nfs: mount to NFS server 'localhost' failed: timed out, retrying Mar 6 12:11:02 blue kernel: rpc.mountd[3778]: segfault at 72e19e45 eip 001afbca esp bfcb3eb4 error 4 V4 hangs like this: # mount.nfs4 localhost:/ /mnt/anon4 -v -v mount.nfs4: pinging: prog 100003 vers 4 prot tcp port 2049 mount.nfs4: Operation not permitted client sends PUTROOTFH; GETFH; GETATTR server sends back PUTROOTFH: NFS4ERR_PERM if you need packet traces, i can send those too.
Yes, rpc.mountd core dumping would cause things hang... It turns out tje mountd-memleak patch that was fixing a memory leak in nfs-utils-1.1.0 was now causing memory to be free prematurely, which in turn was causing the seg fault The next nfs-utils version (1.1.1-2) is currently in the oven and will be ready shortly.... Thanks for taking the time to help with this!!!
Fixed in nfs-utils-1.1.1-2.fc8 which can be found at: http://koji.fedoraproject.org/koji/taskinfo?taskID=498047
-2 works great, thanks!
nfs-utils-1.1.1-2.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nfs-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-2244
nfs-utils-1.1.1-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.