Bug 452415 - NFS mounts fail because nfsd not mounted on /proc/fs/nfsd on server machine
Summary: NFS mounts fail because nfsd not mounted on /proc/fs/nfsd on server machine
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: module-init-tools
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jon Masters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-22 14:40 UTC by Brian Morrison
Modified: 2017-02-27 08:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-19 12:03:27 UTC
Type: ---


Attachments (Terms of Use)

Description Brian Morrison 2008-06-22 14:40:47 UTC
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.

Comment 1 Brian Morrison 2008-07-10 16:30:05 UTC
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.


Comment 2 Brian Morrison 2008-07-14 11:38:25 UTC
<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.


Comment 3 Jon Masters 2008-08-15 19:27:26 UTC
Did you get anything from the logging in the end?

Comment 4 Brian Morrison 2008-08-15 21:51:29 UTC
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.

Comment 5 Brian Morrison 2008-08-19 12:03:27 UTC
No, not seen this happen again with new -108.fc9 kernel and several reboots due to power cuts, so I'm marking it closed.

Comment 6 john cooper 2009-04-20 21:19:48 UTC
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


Note You need to log in before you can comment on or make changes to this bug.