Description of problem: Correctly exported NFS mounts fail to mount with a "Permission denied" error. Version-Release number of selected component (if applicable): module-init-tools-3.4-13.fc9 and nfs-utils-1.1.2-2.fc9 nfs-utils-lib-1.1.1-3.fc9 How reproducible: Has survived 3 reboots on a system updated from F7 to F9. Steps to Reproduce: 1. Boot system 2. Attempt to save mail to a cross mounted NFS mount from another machine. 3. "Permission denied" error occurs Actual results: There is no mount of nfsd on /proc/fs/nfsd, adding this mount manually produces the correct result and NFS mounts become reachable from other systems. Expected results: The nfsd mount should occur when the nfsd module is loaded, using a rule in /etc/modprobe.d/modprobe.conf.dist. This rule exists but for some reason does not perform the mount and NFS mounts fail. No errors are seen in /var/log/messages on the NFS server, only on the NFS client machine. Additional info: These two rules are included in /etc/modprobe.d/modprobe.conf.dist: install nfsd /sbin/modprobe --first-time --ignore-install nfsd && { /bin/mount -t nfsd nfsd /proc/fs/nfsd > /dev/null 2>&1 || :; } remove nfsd { /bin/umount /proc/fs/nfsd > /dev/null 2>&1 || :; } ; /sbin/modprobe -r --first-time --ignore-remove nfsd It appears that the install rule does not correctly work. This installation has worked perfectly on this same machine with Fedora 7 x86_64, and before that Fedora Core 6 and Redhat 9 i386.
This seems to have resolved itself now, possibly only caused by a failure to mount /proc/fs/nfsd on the one occasion during the upgrade. I'm going to mark it closed.
<Sigh> Always happens when you do that. A further reboot of the nfs server has resulted in the /proc/fs/nfsd mount process failing silently. Will try to catch any error messages if this happens again. At present the command in /etc/modprobe.d/modprobe.conf.dist directs errors to /dev/null, but I'll change this temporarily.
Did you get anything from the logging in the end?
No, I have not seen the problem again, but having said that I don't reboot that often. I have a pending reboot after the most recent Fedora kernel update, if I don't see the problem again then I will mark this closed again. I suspect that this is some sort of odd race error that has now disappeared because a fair number of packages have been updated including various nfs related packages.
No, not seen this happen again with new -108.fc9 kernel and several reboots due to power cuts, so I'm marking it closed.
I've seen this same problem surface for the case of NFS support statically built into a kernel, when booting it in a userland installed with a kernel where NFS was compiled as a module. Bottom line is /proc/fs/nfsd isn't mounted on the server and mount attempts fail with: mount: <host>:<mountpoint> failed, reason given by server: Permission denied Supporting a kernel where NFS is statically linked may not be a goal of the installed userland, but given the amount of time required to isolate this failure it arguably should be. In this case the remedy lies in other than module-init-tools. I'm attaching it to this bug as I suspect a single solution will address both scenarios. Note I've seen this problem surface in both FC8 and FC9 installs. # mount localhost:/workspace /mnt/z mount: localhost:/workspace failed, reason given by server: Permission denied # echo $? 32 [failure as seen via 'strace -f rpc.mountd':] open("/proc/fs/nfsd/filehandle", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/proc/fs/nfs/filehandle", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory) # /bin/mount -t nfsd nfsd /proc/fs/nfsd # mount localhost:/workspace /mnt/z # echo $? 0