Description of problem: Access to non-root volumes on remote NFS server stopped working as of latest F-11 update. I assume nfs-utils is the guilty party since the yum log doesn't show any other likely suspect having been updated last night. Version-Release number of selected component (if applicable): nfs-utils-1.2.0-5.fc11.x86_64 How reproducible: 100% Steps to Reproduce: 1. ls /net/hostname 2. ls /net/hostname/some-subdirectory where some-subdirectory is a mount point on remote server Actual results: #1 works, #2 says "No such file or directory" Expected results: Both should work Additional info: Remote server does export these volumes, and has not changed configuration in a long time. Remote server is NFS v3 if it matters. There is nothing at all in /var/log/messages about this. This is kinda urgent for me as I use this capability daily ...
I've confirmed that reverting to nfs-utils-1.2.0-4 un-breaks things for me, so the culprit is unquestionably nfs-utils-1.2.0-permerrors.patch. Looking at the patch, my guess is that there is some condition being generated by my remote server that is being taken as a hard error when it should not be. The server in question is a fairly old HPUX release, and it's possible that you'd not see the error if testing against another Fedora box. Is there any simple way for me to figure out what condition is being reported?
Try 'mount -v' to see that error the server is returning... Also getting a network trace would be good too. Something similar to: tshark -w /tmp/data.pcap host <servername> bzip2 /tmp/data.pcap
OK, I got the tshark traces for you. The first one is done with nfs-utils-1.2.0-4, and captures traffic during this console interaction: [tgl@rh2 ~]$ ls /net/sss2 SD_CDROM/ bin@ dev/ export/ lib@ net/ root/ stand/ usr/ var/ TT_DB/ cdrom/ etc/ home/ lost+found/ opt/ sbin/ tmp/ uucp/ [tgl@rh2 ~]$ ls /net/sss2/home TT_DB/ frank/ lost+found/ postgres/ test/ tgl/ upload/ archive/ gnu/ mac/ ptolemy/ tftp/ tree/ [tgl@rh2 ~]$ The second one is with 1.2.0-5, and captures this: [tgl@rh2 ~]$ ls /net/sss2 home/ opt/ tmp/ usr/ var/ [tgl@rh2 ~]$ ls /net/sss2/home ls: cannot open directory /net/sss2/home: No such file or directory [tgl@rh2 ~]$ In both cases the Fedora machine had just been rebooted, so as to clear anything that might be cached. This more careful testing points up something I'd missed in my first report: -5 isn't even really working for the root filesystem. The subdirectories it shows are only the exported non-root filesystems, not any of the other stuff that is in / on the server. Let me know what else I can do to help debug this.
Ok, thanks for the data... It appears the HPUX server does not support TCP mounts. To verify this please running the following command "rpcinfo -p <HPUX_server> | grep nfs' I'm am assuming the only entries will be: 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs
Oh, yeah, I coulda told you that ... it's UDP-only. (It's old :-()
nfs-utils-1.2.0-6.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/nfs-utils-1.2.0-6.fc11
Please try the above (Comment #8) nfs-utils update tp see if it fixes the problem. If so, please give me some good karma.. Thanks for your help!!
nfs-utils-1.2.0-6.fc11 has been pushed to the Fedora 11 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/F11/FEDORA-2009-10643
Looks good from here, thanks!
nfs-utils-1.2.0-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.