10

I have a problem mounting a NFS share that I can't solve that is driving me nuts. This is the situation:

Three machines involved:
Host A: mandrake, IP 192.168.1.4, NFS server
Host B: athlon64, IP 192.168.1.64, NFS client
Host C: lap-fzs-2, IP 192.168.1.27, NFS client

Host A has an NFS server running which exports a directory that gets mounted by host B. This works flawless and has been working since ages. No problemo. Now host C comes into the picture. Ubuntu 12.04 LTS, modern system. I tried to mount the same share from host A but get a permission denied error:

root@lap-fzs-2:~# mount -t nfs mandrake:/data /data -onfsvers=2
mount.nfs: access denied by server while mounting mandrake:/data

The fact that it works between hosts A and B should be prove that the NFS export per se is working. Here is the info I can give that makes me think it should work. Maybe someone sees what I don't and knows why this fails on the new host C.

Server exports:

[root@mandrake /root]# cat /etc/exports
/suse 192.168.1.0/16(ro,no_root_squash)
/data 192.168.1.0/24(rw)
#/data3 192.168.2.0/24(rw)
#/data 192.168.2.0/16(rw,all_squash,anonuid=500,anongid=500)
#/data3 192.168.2.0/16(rw,all_squash,anonuid=500,anongid=500)

[root@mandrake /root]# exportfs
/suse           192.168.1.0/16
/data           192.168.1.0/24

The portmapper is running, the exports are known and mounted by host B "athlon64".

[root@mandrake /root]# showmount -e
Export list for mandrake:
/data 192.168.1.0/24
/suse 192.168.1.0/16
[root@mandrake /root]# showmount -a
All mount points on mandrake:
atlhon64.acme.local:/data

When the athlon64 host mounts the NFS share, the server log shows success:

Feb 11 20:06:46 mandrake mountd[460]: authenticated mount request from atlhon64.acme.local:770 for /data (/data)

But when the host C tries to mount the same share, the server log shows:

Feb 11 20:12:42 mandrake mountd[460]: refused mount request from lap-fzs-2 for /data (/): no export entry

Host C sees the server, reaches the portmapper and the nfsd, but fail at the permissions.

root@lap-fzs-2:~# showmount -e 192.168.1.4
Export list for 192.168.1.4:
/data 192.168.1.0/24
/suse 192.168.1.0/16


root@lap-fzs-2:~# mount -t nfs -v mandrake:/data /data -onfsvers=2,proto=udp
mount.nfs: timeout set for Mon Feb 11 21:49:23 2013
mount.nfs: trying text-based options 'nfsvers=2,proto=udp,addr=192.168.1.4'
mount.nfs: prog 100003, trying vers=2, prot=17
mount.nfs: trying 192.168.1.4 prog 100003 vers 2 prot UDP port 2049
mount.nfs: prog 100005, trying vers=1, prot=17
mount.nfs: trying 192.168.1.4 prog 100005 vers 1 prot UDP port 636
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting mandrake:/data

I have to use NFSv2 on the client. Using NFSv4 will fail as the server doesn't support it. It fails as it tries to connect via TCP directly to 2049 but the port isn't open. No fallback happens. Using NFSv3 will result in a RPC program/version mismatch.

What am I missing?

Update:
All three machines are on one LAN, on the same switch. There is no firewall active on host C:

root@lap-fzs-2:~# iptables -vnL
Chain INPUT (policy ACCEPT 17 packets, 1853 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 20 packets, 5611 bytes)
 pkts bytes target     prot opt in     out     source               destination

Nor on host A:

[root@mandrake /root]# ipchains -L 
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
10
  • Firewall on Host C (or less likely Host A) ? (What does /sbin/iptables -vnL show ?)
    – davidgo
    Feb 11, 2013 at 21:31
  • Nope, no firewalls, one LAN segment.
    – Florian
    Feb 11, 2013 at 21:57
  • 1
    try exportfs -a command at Host A, then try mount command on Host C. Try explicit hostname or the full IP address in /etc/exports.
    – sawdust
    Feb 11, 2013 at 23:09
  • 1
    How would that help? The server does an exportfs -a at boot time and since this is not a new entry, it's already exported. The exports file didn't change, it's just a new host that should mount it and can't.
    – Florian
    Feb 11, 2013 at 23:13
  • @sawdust your edit contained the right hint: using the full IP address in /etc/exports actually makes it work. I now have the /24 net plus the full IP listed and host C can mount. Haven't tried host B yet. Any idea why this is? I noticed that host B (the working one) did use a version 2 MNT call, while host C resorted to a version 1 MNT call.
    – Florian
    Feb 11, 2013 at 23:44

3 Answers 3

1

Feb 11 20:12:42 mandrake mountd[460]: refused mount request from lap-fzs-2 for /data (/): no export entry

Since the server's rejection notice claims that there is "no export entry" for Host C, then perhaps you should try an unambiguous line in the /etc/exports file with the explicit hostname or the full IP address for C.

Also try issuing an exportfs -a command at the server.
I often have problems accessing my NFS server even after reboots. Explicitly issuing the exportfs -a command is the reliable solution (for me).

2
  • The explicit, repeated exportfs -a didn't change anything for me. Using the full IP address for the one problematic host solved my issue. So while this doesn't explain it and I don't understand it, it was the answer to my problem and what I can recommend to try for others with the same issue.
    – Florian
    Feb 16, 2013 at 16:48
  • Adding an entry for the problematic IP address in /etc/exports resolved my issue as well. Weird.
    – PLA
    Jul 7, 2014 at 15:59
1

Check and see if the UID and GUID for the NFS users are the same on server and client. Also, make sure on server the folder is permission 777. This is my /etc/exports on my server for my client to access.

Create a NFS share directory: (Create each Server with IP, space seperated)

mkdir /var/nfs vim /etc/exports /var/nfs 10.180.82.250(rw,sync,root_squash,anonuid=530,anongid=530,no_subtree_check)

1
  • The UID and GID are not the same. They don't have to be, it works once I got the share mounted on the NFS client. And for the mount operation the user's UIDs should be irrelevant. I do doubt that setting the folder to 777 is a good idea, especially if users can log on to the server. Again, it worked without that once I got it mounted.
    – Florian
    Feb 16, 2013 at 16:51
1

In my case, -o vers=3 is the answer:

$ sudo mount -o vers=3 192.168.172.1:/A/DIR /mnt
  • NFS Server: Ubuntu desktop 12.04 32-bit vmware host
  • NFS Client: Ubuntu server 12.04 64-bit vmware guest (host-only mode)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .