Home / server / Questions / 122750
In Process
zigdon
Asked: 2010-03-16 13:02:41 +0800 CST

NFS: Server says "authenticated mount request", but client sees "access denied"

  • 772

I have two machine, an NFS server (RHEL) and a client (Debian). The server has NFS set up, exporting a particular directory:

server:~$ sudo /usr/sbin/rpcinfo -p localhost
program vers proto   port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper
100024    1   udp    910  status
100024    1   tcp    913  status
100021    1   udp  53391  nlockmgr
100021    3   udp  53391  nlockmgr
100021    4   udp  53391  nlockmgr
100021    1   tcp  32774  nlockmgr
100021    3   tcp  32774  nlockmgr
100021    4   tcp  32774  nlockmgr
100007    2   udp    830  ypbind
100007    1   udp    830  ypbind
100007    2   tcp    833  ypbind
100007    1   tcp    833  ypbind
100011    1   udp    999  rquotad
100011    2   udp    999  rquotad
100011    1   tcp   1002  rquotad
100011    2   tcp   1002  rquotad
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100005    1   udp   1013  mountd
100005    1   tcp   1016  mountd
100005    2   udp   1013  mountd
100005    2   tcp   1016  mountd
100005    3   udp   1013  mountd
100005    3   tcp   1016  mountd

server$ cat /etc/exports
/dir      *.my.domain.com(ro) 

client$ grep dir /etc/fstab
server.my.domain.com:/dir   /dir      nfs tcp,soft,bg,noauto,ro 0 0

All seems well, but when I try to mount, I see the following:

client$ sudo mount /dir
mount.nfs: access denied by server while mounting server.my.domain.com:/dir

And on the server I see:

server$ tail /var/log/messages
Mar 15 13:46:23 server mountd[413]: authenticated mount request from client.my.domain.com:723 for /dir (/dir)

What am I missing here? How should I be debugging this?

nfs debian rhel4

7 Answers

  1. I've seen this if your /etc/hosts.allow and /etc/hosts.deny are not correct; check those files for a line with portmap in it and either comment it out (unsecure if you're not behind a firewall) or set the line on the client/server to be your specific subnet.

    So for instance, in /etc/hosts.allow:

    portmap: 192.168.0.0/16

    ...and comment out whatever is in /etc/hosts.deny to make only hosts.allow active. NFS uses tcpwrappers and these files to control access along with what's in /etc/exports.

    • 3

  2. your rpcinfo indicates NFS is trying to connect over UDP. it appeared NFSv4 is no longer working over UDP but is expecting TCP to be used.

    the linux kernel for example is trying to mount rootfs over UDP even for the NFSv4 and needed a special argument to be added at the tail of nfsroot. example: nfsroot=192.79.143.131:/diskless/client01,tcp

    • 1

  3. I faced the same problem from a Debian 10.2 server with a macOS client. My solution:

    On the NFS server, add the insecure option to the share in /etc/exports and re-run exportfs -r

    Source here.

    • 1

  4. Is it broken from all machines or just one? Is the nfsd pseudo-filesystem mounted on /proc/fs/nfsd on the server?

    • 0

  5. Unfortunately, rebooting the server solved the issue, so I still don't know why it was happening, but it's not anymore.

    • 0

  6. I have faced the same problem, my server is a ubuntu machine and my client is a macbook air. the solution has been in the past to restart the server machine, but since I use it as a media center, that is not always fun. so, what I did to fix it was:

    on server, edit /etc/exports

    pico /etc/exports

    then I flush it 

    exportfs

    and add a new line, with the spesific ip of the client with the problem (my normal share is network wide), then I unmount the share on the client, and re-mount it again, and now it works.

    PS: but it did not show up as a shortcut on the left in my finder as normal, I had to find it at my mount point

    • 0

  7. I experienced the same and very specific scenario by trying to load a kernel using NetBSD pxeboot bootloader. It actually talks NFSv2. 8 years ago, this might also be the root cause, your Debian client and RHEL server did not talk the same language. You could have enabled NFSv2 by adding -V2 as an argument to rpc.mountd. You can also eventually disable v3 and v4 with -N3,4.

    • 0