5

There's plenty of references to this error on Goggle, and even a question here with the same title, but it seems that "access denied by server while mounting" is a catch-all error. I've tried suggestions that others have used to fix this problem, but they did not work in my case.

I'm trying to set-up a Kerberos-based NFS file server with shared homes for a Linux network. I'm using Ubuntu 11.04 Servers and clients.

When trying to mount a share using:

mount 192.168.1.115:/export/home/ /media/tmp

I get:

mount.nfs: access denied by server while mounting 192.168.1.115:/export/home/

This is the same if I mount it from a client machine or from the server itself.

On the server, in /var/log/syslog I get:

Aug 25 06:22:37 nfs mountd[1580]: authenticated mount request from
       192.168.1.115:835 for /export/home (/export/home)    

Aug 25 06:22:37 nfs mountd[1580]: authenticated unmount request from
       192.168.1.115:766 for /export/home (/export/home)

Which is odd, since it says it's authenticated the request, not denying it.

/etc/exports:

/export *(rw,fsid=0,crossmnt,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5)
/export/home    *(rw,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5)


On client:

me@dt1:/$ rpcinfo -p 192.168.1.115

   program vers proto   port
    100000    2   tcp    111  portmapper
    100024    1   udp  37320  status
    100024    1   tcp  48460  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  58625  nlockmgr
    100021    3   udp  58625  nlockmgr
    100021    4   udp  58625  nlockmgr
    100021    1   tcp  49616  nlockmgr
    100021    3   tcp  49616  nlockmgr
    100021    4   tcp  49616  nlockmgr
    100005    1   udp  45627  mountd
    100005    1   tcp  60265  mountd
    100005    2   udp  45627  mountd
    100005    2   tcp  60265  mountd
    100005    3   udp  45627  mountd
    100005    3   tcp  60265  mountd

Any suggestions I could try?

Andy Smith
  • 1,798
  • 13
  • 15
Nick
  • 4,433
  • 29
  • 67
  • 95

3 Answers3

1

Maybe this will help:

It also happened to me when I did not insert the share path correctly.

# mount 192.168.2.101:/share /local/folder

has returned this error, but when I changed to

# mount 192.168.2.101:/full/path/to/share /local/folder

it worked great..

Just put the exact share as you did in /etc/exports file

Andy Smith
  • 1,798
  • 13
  • 15
Chris Gregory
  • 11
  • 1
0

I guess this has solved itself, or gone away in some form since it is quite old.

But check that /proc/fs/nfsd is mounted on the server.

If not: mount -t nfsd nfsd /proc/fs/nfsd

espenfjo
  • 1,676
  • 2
  • 13
  • 15
0

I once switched hardware and the OS - Fedora Core - and forgot that NetworkManager would decide that the network controller was now unknown so instead of assigning it the fixed IP address of the configured controller, it set it to DHCP, and, thus, the server rejected the connection from this now unknown system.

NetworkManager creates a new file in /etc/sysconfig/network-scripts/ for the "new" controller, while the old script remained.

The solution was to edit the old "script" and change the line (I opted to leave the old line as a comment) which starts "HWADDR" to equal the equivalent value in the new file, which in my case can also be obtained via ifconfig as the value "ether", and then delete the new file. Restart as appropriate until the old IP address is restored....

Richard T
  • 1,130
  • 11
  • 26