Bug 264661

Created attachment 181621 [details]
tshark capture of a couple of mount attempts

Attaching capture of a couple of mount attempts

Just as I suspected, the server is denying the mount due to
(I'm guessing) your exports. 

Fire up wiresharke and read in the data file you posted.
Then use 'rpc.program == 100005' as a display filter 
and you will see for your self, that the server is 
returning an "ERR_ACCESS"

Upgraded elwood to rawhide:
[root@elwood ~]# rpcinfo -p pinky
rpcinfo: can't contact portmapper: RPC: Unknown host

while other machines can get rpcinfo:
[root@vito ~]# rpcinfo -p pinky
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
[...truncated...]

And get rpcinfo from the rawhide box as well:

[root@vito ~]# rpcinfo -p elwood
   program vers proto   port
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
[...truncated...]

In fact, FC6 is now able to mount the rawhide machine's share, but still no go
vice-versa, or from any other FC6 machine

hmm... this is a strange one... On elwood (the rawhide machine) 
can you post a network trace of that failure? It may
shed some light on whats going on.... 

In general, a "Unknown Host" means its a DNS problem but
I'm assuming other apps are not having the same problem..

Question: is IPv6 enabled on any of your network interfaces?

Created attachment 184481 [details]
network trace mounting pinky /home nfs share from elwood

Attached network trace; please note that the valid NFS traffic you see is a
mount from pinky (10.10.10.50) on elwood's(10.10.10.58) /data/backup share

Still gets ERR_ACCESS on:
[root@pinky ~]# cat /etc/exports 
/home *.kanarip.com(rw,insecure,sync,no_root_squash)

and:

[root@elwood ~]# rpcinfo -p pinky
rpcinfo: can't contact portmapper: RPC: Unknown host
[root@elwood ~]# rpcinfo -p localhost
rpcinfo: can't contact portmapper: RPC: Unknown host
[root@elwood ~]# rpcinfo -p 127.0.0.1
rpcinfo: can't contact portmapper: RPC: Unknown host

Creating attachment doesn't set back to assigned ;-)

Additional info for elwood (rawhide, the one with the rpcinfo problems):
[root@elwood ~]# rpm -qv rpcbind
rpcbind-0.1.4-7.fc8

One more thing, these are both FC6 machines, one that is working as an NFS
server (vito), and one that isn't (pinky):

[root@vito ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
[root@vito ~]# uname -a
Linux vito.kanarip.com 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 19:28:18 EST 2007
i686 i686 i386 GNU/Linux
[root@vito ~]# cat /etc/fedora-release
Fedora Core release 6 (Zod)
[root@vito ~]# rpm -qv nfs-utils
nfs-utils-1.0.10-14.fc6
[root@vito ~]# 


[root@pinky ~]# mount
/dev/hda3 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
none on /sys type sysfs (rw)
/dev/md0 on /home type ext3 (rw,usrquota,grpquota)
elwood.kanarip.com:/data/backup on /backup type nfs (rw,tcp,addr=10.10.10.58)
[root@pinky ~]# uname -a
Linux pinky.kanarip.com 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 2007
i686 i686 i386 GNU/Linux
[root@pinky ~]# cat /etc/fedora-release 
Fedora Core release 6 (Zod)
[root@pinky ~]# rpm -qv nfs-utils
nfs-utils-1.0.10-14.fc6
[root@pinky ~]# 

Manually mounting:

nfsd on /proc/fs/nfsd type nfsd (rw)

solved the problem. Any reason why this mount failed?

OK, definitely solved (I can work again ;p), but unsure why nfsd isn't mounted
(haven't tested reboot) Will reopen if necessary. Thanks Steve!

WOW... Take a look at your /etc/modprobe.d/modprobe.conf.dist file
and make sure the following lines exists:

install nfsd /sbin/modprobe --first-time --ignore-install nfsd && \
 { /bin/mount -t nfsd nfsd /proc/fs/nfsd > /dev/null 2>&1 || :; }

install sunrpc /sbin/modprobe --first-time --ignore-install sunrpc && \
 { /bin/mount -t rpc_pipefs sunrpc /var/lib/nfs/rpc_pipefs > /dev/null 2>&1 ||:; }

Both  /proc/fs/nfsd and /var/lib/nfs/rpc_pipefs should be mounted
during modprobe time....

We've just run into this problem on two of our RHEL5.5 systems.  That is, systems that had previously been exporting NFS filesystems without a problem suddenly started reporting "permission denied" despite entries like this in /etc/exports:

  /mnt/somefilesystem *(ro)

The solution was to manually mount /proc/fs/nfsd.  

/etc/modprobe.d/modprobe.conf.dist is unmodified from the stock configuration and includes the necessary install/remove rules:

  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

This happened on unrelated systems, maintained by two distinct groups of people.

Since the mount operation is idempotent (if the filesystem is already mounted, running "mount -t nfsd nfsd /proc/fs/nfsd" simply reports an error), we've simply made this part of the NFS startup script.  It seems that this might be a good idea in general.