Red Hat Bugzilla – Bug 218994
Permission denied when trying to mount a nfs share
Last modified: 2007-11-30 17:11:51 EST
Description of problem:
Mounting a NFS share between an i686 laptop and x86_64 workstation fails with
permission denied. The same laptop can mount NFS shares from other machines just
fine (I tried serving NFS from another FC5 i686 workstation, and a FC4 i686 server).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ryvius:# cat /etc/exports
2. neeya:# mount.nfs ryvius:/home/media /mnt/media -v
mount: trying 192.168.2.15 prog 100003 vers 3 prot tcp port 2049
mount: trying 192.168.2.15 prog 100005 vers 3 prot udp port 676
mount: ryvius:/home/media failed, reason given by server: Permission denied
Mount should succeed.
# showmount -e ryvius
Export list for ryvius:
There are no unusual log entries on the server:
Dec 8 23:52:29 ryvius mountd: authenticated mount request from
neeya.pekin.waw.pl:922 for /home/media (/home/media)
One oddity I noticed - running rpc.mountd under strace reveals:
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)
On another FC4 i686 machine that acts as a NFS server, the file
I have no more clues.
Forgot to add: neither the client nor the server have selinux or iptables enabled.
Looks like shutting down all NFS services, modprobe -r nfs nfsd and restarting
those services caused it to work again, but I wonder what happened there.
This looks like it could be a mount bug that is fixed in
the updated nfs-utils package. So please 'yum update nfs-utils'
to the nfs-utils-1.0.10-4.fc6 package...
(In reply to comment #3)
> This looks like it could be a mount bug that is fixed in
> the updated nfs-utils package. So please 'yum update nfs-utils'
> to the nfs-utils-1.0.10-4.fc6 package...
You'll notice that in comment #1 I wrote that I was using the updated
It sounds like something happen to your exports on the
server sided... If this happens again... please try
'exportfs -arv' to see if it clear up the problem...
Confirming I saw the same behavior now, running on RawHide:
No restarts of anything in userland helped. Just later RMMOD of everything and
a simple `/etc/init.d/nfs restart' (START would be probably enough) got it working.
No EXPORTFS was run to get it working. No reproducibility guide, though.
There is no failure or warning messages in /var/log/messages
that might give a clue as to what is happeing?
There really wasn't any at least in the case of mine.
Also I believe it could get reassiged to `kernel' at this point although it
won't help much in its resolving.
There was nothing in my case. I haven't been able to reproduce it ever since.
Could you please post a bzip2 binary tethereal network trace
of of the failing mount? Something similar to
tethereal -w /tmp/bz218994.pcap host <server>
Also is Selinux in the picture?
(In reply to comment #10)
> Could you please post a bzip2 binary tethereal network trace
> of of the failing mount? Something similar to
> tethereal -w /tmp/bz218994.pcap host <server>
I did not store such dump but I was checking it that time by ethereal and there
was nothing interesting. There was a mount request for / and some (do not
remember the error code) access denied sent back by the (broken) server.
Despite the server logger `authenticated mount request from ... for / (/)'.
> Also is Selinux in the picture?
No SELinux on my machine (SELINUX=disabled).
Are the clients multi-homed? Could it be possible that
the nfs request is coming from an IP address that is
not being exported?
I'm noting that the exported filesystem is only exported
to one client... does using the '*' wild-card (i.e. *(rw,async) )
make any difference?
Client was a XEN guest with single IP in my case.
I was trying also the '*' export there.
I was also using `exportfs -rav' and `exportfs -ravf'.
(In reply to comment #12)
> Are the clients multi-homed? Could it be possible that
> the nfs request is coming from an IP address that is
> not being exported?
Not in my case. Single IP for the client and server.
> I'm noting that the exported filesystem is only exported
> to one client... does using the '*' wild-card (i.e. *(rw,async) )
> make any difference?
I still cannot reproduce it again. I'll post back if anything happens.
... I think I'm hitting the same problem since the last update.
I cannot mount share from other machines; I can't mount my own shares from
- No errors, /var/log/messages is clear. (Apart from the normal "authenticated
mount request from...")
- I can only see the EACCESS using wireshark.
- hosts.allow/deny are empty.
- Putting wild-card in /etc/exports doesn't solve the problem.
$ rpm -qa | grep nfs-utils
WRT Comment #15.... Please post the output of mount -v which should tell you
why the mount is failing also you need to run wireshare as root
which should take care of the EACCESS problem...
$ mount -v 192.168.1.2:/mnt/Work /tmp/mnt
mount: no type was given - I'll assume nfs because of the colon
mount: trying 192.168.1.2 prog 100003 vers 3 prot tcp port 2049
mount: trying 192.168.1.2 prog 100005 vers 3 prot udp port 2050
mount: 192.168.1.2:/mnt/Work failed, reason given by server: Permission denied
$ exportfs | grep Wrok
$ ifconfig eth0 | grep "inet addr"
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
$ tethereal -i lo
0.003840 192.168.1.2 -> 192.168.1.2 Portmap V2 GETPORT Call MOUNT(100005)
0.003869 192.168.1.2 -> 192.168.1.2 Portmap V2 GETPORT Reply (Call In 21)
0.003914 192.168.1.2 -> 192.168.1.2 MOUNT V3 NULL Call
0.003987 192.168.1.2 -> 192.168.1.2 MOUNT V3 NULL Reply (Call In 23)
0.004047 192.168.1.2 -> 192.168.1.2 MOUNT V3 MNT Call /mnt/Work
0.052859 192.168.1.2 -> 192.168.1.2 MOUNT V3 MNT Reply (Call In 25)
Have you tried my workaround from Comment #2?
I couldn't rmmod nfsd - even though all rpc/nfs-related services are down, the
module usage count is still > 0.
After a reboot, I'm still getting ERR_ACCESS.
then it might be a different bug. Try running rpc.mountd on the server under
strace and see if that gives any more clues.
Do the files /proc/fs/nfsd/filehandle and /proc/fs/nfs/filehandle exist on the
> 0.052859 192.168.1.2 -> 192.168.1.2 MOUNT V3 MNT Reply (Call In 25)
hmm... its mountd denying the mount...
Please added the '-d all' argument to mountd
(via /etc/sysconfig/nfs) and redstart mountd.
Then please post the debugging output which
should be in /var/log/messages.
Steve and Dominik,
I've finally had time to install F7 on the problematic machine and it solved the
Once I have some time to, I'll pull the FC6 image from my backups and do some
stracing on mountd.
Thank you for your time and effort... at this point I'm going to
close this bug, but please reopen it if the problem does