Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|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

3 Answers 3

Check if there are some files in /proc/fs/nfsd.

If not, issue this comand:

mount -t nfsd none /proc/fs/nfsd

If there are, I don't know either.

share|improve this answer

I usually debug this kind of problems with tcpdump. The raw packet capture always tells something or other.

Start the packet capture from both NFS client and server.

tcpdump -s0 -i ethX -w /tmp/tcpdump_from_client.pcap host <NFS-server-IP>
tcpdump -s0 -i ethX -w /tmp/tcpdump_from_server.pcap host <NFS-client-IP>

Replace ethX with eth1 or 2 or whatever you have.

Then, look for RPC transmissions in the packet capture. I prefer wireshark and see the TCP section. I have often seen it provides some kind of clue.

Next step would be to enable NFS debug logs.

I would highly request you to keep the tcpdump data to yourself or get it checked with someone you trust.

share|improve this 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?
share|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
    
Is root squash on? –  papashou Feb 2 '13 at 16:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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