up vote 0 down vote favorite
share [g+] share [fb]

I have two RedHat 4 Servers. The client is 4.6, the server is 4.5. I'm attempting to mount a share from the server, onto the client via NFS.

The /etc/exports configuration is as follows:

/opt/data/config bkup(rw,no_root_squash,async)
/opt/data/db bkup(rw,no_root_squash,async)

exportfs returns these (among other) shares, nfs is running according to ps output.

I've been attempting to use autofs on the client, but have opted to just mount the share manually considering the issues I'm having.

So, I issue the mount request:
mount dist:/opt/data/config /mnt/config

mount: dist:/opt/data/config failed, reason given by server: Permission denied

Ok, so let's see what the server has to say for itself.

May 6 23:17:55 dist mountd[3782]: authenticated mount request from bkup:662 for /opt/data/config (/opt/data/config)

It says it allowed the mount to take place.

How can I diagnose why the client and server are disagreeing on the result?

link|improve this question

hmmm....do you have a firewall on one or both of the systems? – mdpc May 6 '11 at 23:37
Nupe. Private servers, private interfaces, no iptables or other firewall solution in place. Same network too. – VxJasonxV May 6 '11 at 23:49
A shot in the dark: name resolution problems? Maybe IP addresses in the configuration files would help? – PaweÅ‚ Brodacki May 7 '11 at 5:49
(1) If it was an rDNS issue, the nfs log would talk about rejecting the mount request due to the name not matching the /etc/exports record(s). (2) If it were a forward DNS issue, the client wouldn't reach the server at all. – VxJasonxV May 7 '11 at 7:31
feedback

1 Answer

This is a good example of the difference between authentication and authorization. In this scenario the authentication succeeded, but the authorization on the host's directory is likely to be the problem. To test, you can try setting the host's directory permissions recursively to 777 (don't forget to change this again later).

Things to check:

  • Are the username and uuid of the user on the client and the host the same?
  • Are permissions correctly set on the host?
  • Does NFS on the host server have correct permissions to access the files it is supposed to share? ie. Is NFS running as root, and if not, do the files it is trying to access have correct permissions set to allow them to be accessed by the NFS daemon itself?
link|improve this answer
I'm mounting the share as root, and the folder is standard, mode 755 and all that. If it were a permissions problem, standard utilities (ls, cat, vim, etc.) would fail when attempting to edit the contents of the folder itself. – VxJasonxV May 7 '11 at 16:24
Beyond that. Surely the SERVER would reject the client if it were the problem you describe? – VxJasonxV May 9 '11 at 6:31
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.