Re: Permission denied when mounting NFS (was okay before)

[Benny Halevy <bhalevy@panasas.com>]

On Sep. 29, 2008, 20:26 +0300, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Mon, Sep 29, 2008 at 12:53:16PM +0800, howard chen wrote:
>> Hello all,
>>
>> On Mon, Sep 29, 2008 at 12:21 PM, howard chen <howachen@gmail.com> wrote:
>>> Yes, tested, and same error... Also tried "no_root_squash"...
>>>
>>> Really have no idea what is going on...
>>>
>> Problem solved by adding the following line in fstab, according to
>> this site: http://www.linuxforums.org/forum/linux-networking/44779-nfs-permission-denied-error.html
> 
> Huh.  Surely mountd or knfsd could have given a more helpful error
> message, at least....

I agree.
I've just hit this problem again today (running Fedora 9).
(and I think http://bugzilla.redhat.com/show_bug.cgi?id=218994 might
be the same thing BTW)

rpc.mountd just prints
authenticated mount request from 192.168.0.140:669 for /usr0/export
even when invoked with --debug all.

However it denies access.  Here's tshark -V output:

Remote Procedure Call, Type:Call XID:0xee9360da
    Fragment header: Last fragment, 124 bytes
        1... .... .... .... .... .... .... .... = Last Fragment: Yes
        .000 0000 0000 0000 0000 0000 0111 1100 = Fragment Length: 124
    XID: 0xee9360da (4002635994)
    Message Type: Call (0)
    RPC Version: 2
    Program: MOUNT (100005)
    Program Version: 3
    Procedure: MNT (1)
    Credentials
        Flavor: AUTH_UNIX (1)
        Length: 68
        Stamp: 0x004235f6
        Machine Name: pangw.bhalevy.com
            length: 17
            contents: pangw.bhalevy.com
            fill bytes: opaque data
        UID: 0
        GID: 0
        Auxiliary GIDs
            GID: 0
            GID: 1
            GID: 2
            GID: 3
            GID: 4
            GID: 6
            GID: 10
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
Mount Service
    [Program Version: 3]
    [V3 Procedure: MNT (1)]
    Path: /usr0/export
        length: 12
        contents: /usr0/export

...
Remote Procedure Call, Type:Reply XID:0xee9360da
    Fragment header: Last fragment, 28 bytes
        1... .... .... .... .... .... .... .... = Last Fragment: Yes
        .000 0000 0000 0000 0000 0000 0001 1100 = Fragment Length: 28
    XID: 0xee9360da (4002635994)
    Message Type: Reply (1)
    [Program: MOUNT (100005)]
    [Program Version: 3]
    [Procedure: MNT (1)]
    Reply State: accepted (0)
    [This is a reply to a request in frame 3474]
    [Time from request: 0.000868000 seconds]
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
    Accept State: RPC executed successfully (0)
Mount Service
    [Program Version: 3]
    [V3 Procedure: MNT (1)]
    Status: ERR_ACCESS (13)

Running strace rpc.mountd -F --debug all shows:
...
open("/proc/fs/nfsd/filehandle", O_RDWR) = -1 ENOENT (No such file or directory)
open("/proc/fs/nfs/filehandle", O_RDWR) = -1 ENOENT (No such file or directory)


> 
>> nfsd /proc/fs/nfsd nfsd auto,defaults 0 0

doping this manually using
mount -t nfsd nfsd /proc/fs/nfsd
does the same trick

>>
>>
>> This is really funny as I never have this option in my other NFS servers....
>>
>> Anyone know the reason? Redhat's bug?
> 
> It looks like nfsd is supposed to be mounted on load of the nfsd module,
> by a line in /etc/modprobe.d/modprobe.conf.

Right.

# grep nfsd /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

> 
> (Maybe you built a new kernel with nfsd built-in instead of built as a
> module?)
> 
> But I thought nfs-utils was supposed to fall back on old behavior when
> the nfsd filesystem wasn't found.

Doesn't seem so.

Steve: any chance this bug is fixed anywhere?

Benny

> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html