Bug 125345 - nfs-utils-1.0.6-21EL and 2.6.6 kernel incompatibility
nfs-utils-1.0.6-21EL and 2.6.6 kernel incompatibility
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-04 18:12 EDT by Joe Korty
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-14 14:06:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Korty 2004-06-04 18:12:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux)

Description of problem:
nfs-utils 1.0.6-21 does not allow clients to mount any of its filesystems when a 2.6.6 kernel (from ftp.kernel.org) is booted.  Permission denied messages are returned to the client.  The version of nfs-utils that comes with Enterprise WS 3 (1.0.6-7) does permit client mounts when running 2.6.6 kernels.

The only difference in the sources of 1.0.6-7 and 1.0.6-21
is a few lines that used to test these files for existance:

    /proc/fs/nfs/filehandle
    /proc/fs/nfsd/filehandle

instead now test for

    /proc/net/rpc/auth.unix.ip/channel
    /proc/net/rpc/nfsd.export/channel
    /proc/net/rpc/nfsd.fh/channel

In either case if the full set of files checked exist then an nfsd(8) feature involving caching is turned on (exactly what this is I do not know).  The two /proc files that 1.0.6-7 checks for do not exist in any of the serval stock 2.4 or 2.6 kernel that I checked.  Therefore a significant amount of code in nfs-utils's nfsd(8) daemon may never have been exercised.  But in the 2.6.x kernels, the 2nd set of three files do exist.

The net effect is that nfsd(8) code that appears to have never been used before suddenly starts getting used, when the kernel is a 2.6 kernel and the nfs-utils tools is at rev -21


Version-Release number of selected component (if applicable):
nfs-utils-1.0.6-21

How reproducible:
Always

Steps to Reproduce:
1.install nfs-utils-1.0.6-21
2.download a 2.6.6 kernel from ftp.kernel.org, build and boot
3.export a filesystem
4.try to mount that filesystem from a remote (client) system   

Actual Results:  mount: bubbles:/root failed, reason given by server: Permission denied

Expected Results:  successful mount

Additional info:
Comment 2 Steve Dickson 2004-06-14 14:06:42 EDT
Configuration not supported. Although if you added following
lines to /etc/fstab and reboot, things might start working...

/etc/fstab:
nfsd                    /proc/fs/nfsd           nfsd    defaults 0 0 
sunrpc                  /var/lib/nfs/rpc_pipefs rpc_pipefs defaults 0 0
Comment 3 Carlo Wood 2004-10-09 16:15:37 EDT
I am using nfs-utils-1.0.6-22 and "Linus" kernel 2.6.8.
Adding those two lines to /etc/fstab does not help, I still
get:

jolan:/home/carlo>mount /usr/src
mount: ansset:/usr/src failed, reason given by server: Permission denied

On the NFS server I have:

/etc/rc.d/init.d>./nfs restart
Shutting down NFS mountd:                                  [  OK  ]
Shutting down NFS daemon:                                  [  OK  ]
Shutting down NFS quotas:                                  [  OK  ]
Shutting down NFS services:                                [  OK  ]
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]
Starting NFS4 idmapd: Error: RPC MTAB does not exist.
/etc/rc.d/init.d>exportfs -ra
/etc/rc.d/init.d>cat /var/lib/nfs/xtab
/etc/rc.d/init.d>cat /proc/fs/nfs/exports
# Version 1.1
# Path Client(Flags) # IPs


What am I doing wrong?
Am I forced to start to use fedora patched kernels?
I often want to use the LATEST kernel - not the one that
is provided by a distribution!
Comment 4 Carlo Wood 2004-10-09 16:37:43 EDT
Sorry, that error "Error: RPC MTAB does not exist." shows that
I didn't mount the addition lines in the fstab yet.
But, also after:

/etc/rc.d/init.d>mount -t rpc_pipefs sunrpc /var/lib/nfs/rpc_pipefs/
/etc/rc.d/init.d>mount /proc/fs/nfsd
/etc/rc.d/init.d>./nfs restart
Shutting down NFS mountd:                                  [  OK  ]
Shutting down NFS daemon:                                  [  OK  ]
Shutting down NFS quotas:                                  [  OK  ]
Shutting down NFS services:                                [  OK  ]
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]
Starting NFS4 idmapd:                                      [  OK  ]
/etc/rc.d/init.d>cat /proc/fs/nfs/exports
# Version 1.1
# Path Client(Flags) # IPs


Same thing.

I am not the only one with this problem, for example:

http://www.redhat.com/archives/fedora-list/2004-June/msg04587.html

I cannot find a solution anywhere.
Please add the solution for this problem here!
Comment 5 Vlad 2004-10-17 17:47:29 EDT
That 2 lines in fstab is VERY GOOD and dont forget REBOOT your comp.
It works for me ONLY after reboot.

/etc/fstab:
nfsd                    /proc/fs/nfsd           nfsd    defaults 0 0 
sunrpc                  /var/lib/nfs/rpc_pipefs rpc_pipefs defaults 0 0

/Vlad
Comment 6 Carlo Wood 2005-02-13 11:44:13 EST
I am now running 2.6.10 (although that might not make a difference),
and I know the 'answer' to my own question above:

Unlike what the NFS HOWTO is saying, /proc/fs/nfs/exports
ONLY shows what you have attempted to mount.
It does NOT reflect /etc/exports one on one, but only what is both
in /etc/exports AND has been attempted to mount (whether or not
that succeeded) and was autheticated (see /var/log/messages).

I sent the following information to the nfs mailinglist:

Please add the following text to your NFS-HOWTO,
chapter 7.3 paragraph a.  It would have saved me
me four hours if this information would have been
added before; and hopefully will help people in
the future with the same problem.


The error, on the client side, "failed, reason given by server:
Permission denied"
is the result of a packet that is sent from the server to the client.
However, the meaning of this packet is NOT 'permission denied'.
That is only one of the possible reasons.

Look, on the server, in /var/log/message and you can find
any of two messages, for example,

1) Jan 31 04:23:14 ansset rpc.mountd: refused mount request from
jolan.ansset-jolan for /usr (/): not exported

This means there is REALLY a permission problem.  The existing
text in the HOWTO is then appropriate.

2) Jan 31 04:26:07 ansset rpc.mountd: authenticated mount request from
jolan.ansset-jolan:734 for /usr/src (/usr/src)

In this case something else is going on.  The mount daemon authenticates
the request - but still sents out a packet of 'refusal'.  A possible
reason
for this is when the mount daemon failed to complete its task of testing
AFTER it already wrote to syslog (a "bug" in mountd if you ask me).

One very important reason that people might run into this error
is therefore when the following line is missing from there /etc/fstab
on the server:

nfsd            /proc/fs/nfs    nfsd    defaults        0 0

If this is missing, than /proc/fs/nfs will only contain the
'file' /proc/fs/nfs/exports.  And not, for example,
/proc/fs/nfs/filehandle.

If one does an strace on rpc.mountd during a request, while
/proc/fs/nfs is not mounted, then one will first see it write
'rpc.mountd: authenticated mount request' to syslog, and later
fail with something like:

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)
sendmsg(6, {msg_name(16)={sa_family=AF_INET, sin_port=htons(776),
sin_addr=inet_addr("192.168.2.1")},
msg_iov(1)=[{"Y:r\211\0\0\0\1\0\0\0\0\0\0\
0\0\0\0\0\0\0\0\0\0\0\0\0\r", 28}], msg_controllen=24,
msg_control=0x80015dd0, , msg_flags=0}, 0) = 28

This latter (udp) packet is 100% equivalent to what it sends when it
refuses a mount based on it not being exported.  Hence, the same error
message
on the client side (failed, reason given by server: Permission denied).
(Don't mind the first 4 bytes, which will be equal to the request packets
prefix and have no other meaning).
Comment 7 Philippe Gregoire 2005-04-14 11:22:43 EDT
You have to compile NFS as module to see /proc/fs/nfs* special files.
When the NFS code is compiled in the kernel, theses devices do not appear
automatically

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