[SOLVED] NFS does not mount without nolock option from one NFS server, but mounts correctly from the other
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When I try to mount NFS exports from server1 and server2 in client1, I can mount from server1 without the "nolock" option, but cannot do so for the exports from server2.
Code:
root@client1:/nfs# cat /etc/fstab
server1:/export/data /nfs/data nfs rw,async,hard,intr 0 0
server2:/export/home /nfs/home nfs rw,nolock,async,hard,intr 0 0
server2:/export/repo /nfs/repo nfs rw,async,hard,intr 0 0
root@client1:/nfs# mount -av
/ : ignored
/boot/efi : already mounted
/scratch : already mounted
none : ignored
mount.nfs: timeout set for Thu Aug 10 20:57:17 2017
mount.nfs: trying text-based options 'hard,intr,vers=4,addr=server1.ip,clientaddr=client1.ip'
/nfs/data : successfully mounted
mount.nfs: timeout set for Thu Aug 10 20:57:17 2017
mount.nfs: trying text-based options 'nolock,hard,intr,vers=4,addr=server2.ip,clientaddr=client1.ip'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'nolock,hard,intr,addr=server2.ip'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying server2.ip prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying server2.ip prog 100005 vers 3 prot UDP port 53584
/nfs/home : successfully mounted
mount.nfs: timeout set for Thu Aug 10 20:57:17 2017
mount.nfs: trying text-based options 'hard,intr,vers=4,addr=server2.ip,clientaddr=client1.ip'
mount.nfs: mount(2): No such file or directory
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
root@client1:/nfs# systemctl status rpc-statd
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
Loaded: loaded (/lib/systemd/system/rpc-statd.service; disabled; vendor preset: enabled)
Active: active (running) since Thu 2017-08-10 19:49:21 CDT; 1h 36min ago
Process: 3034 ExecStart=/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=0/SUCCESS)
Main PID: 3036 (rpc.statd)
CGroup: /system.slice/rpc-statd.service
└─3036 /sbin/rpc.statd --no-notify
root@client1:/nfs# cat /etc/hosts.deny
ALL: ALL
root@client1:/nfs# cat /etc/hosts.allow
sshd:client1, server1, server2
rpcbind:client1, server1, server2
The error mentions rpc.statd service, but it seems to be running!
I thought missing octet indicates all possible numbers in that place. At least that's how it works for ssh daemon in my other systems where I have only first two octets in the hosts.allow, e.g.
Code:
sshd: xxx.yyy.
Quote:
Originally Posted by AwesomeMachine
You might also explicitly enable rpc.statd.service
Code:
$ service rpc.statd.service enable
Code:
$ sudo service rpc.statd.service enable
rpc.statd.service: unrecognized service
So instead I tried,
Quote:
systemctl enable/start/restart rpcbind.service
But nothing changes.
Also, as I mentioned in my original log, rpc-statd seems to be running:
Code:
$ systemctl status rpc-statd
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
Loaded: loaded (/lib/systemd/system/rpc-statd.service; disabled; vendor preset: enabled)
Active: active (running) since Thu 2017-08-10 19:49:21 CDT; 12h ago
Main PID: 3036 (rpc.statd)
CGroup: /system.slice/rpc-statd.service
└─3036 /sbin/rpc.statd --no-notify
Aug 10 20:21:33 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 10 20:21:33 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 10 20:21:33 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 10 20:54:35 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 10 20:55:17 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 10 21:21:06 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 10 21:46:46 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 10 21:50:41 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 11 08:13:01 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Aug 11 08:15:05 client1 systemd[1]: Started NFS status monitor for NFSv2/3 locking..
This makes me suspect that one of the required directories is missing. I'm guessing that the shared directories do indeed exist on the servers, but that one of the directory mount points is missing on the client.
This makes me suspect that one of the required directories is missing. I'm guessing that the shared directories do indeed exist on the servers, but that one of the directory mount points is missing on the client.
THanks IsaacKuo. But the directories do exist in right places. In fact, if I add the 'nolock' option, they mount.
What are the file systems on the server side? I have to do some weird stuff to get nfs shares in tmpfs to work properly. There may be issues with other file system types also.
What are the file systems on the server side? I have to do some weird stuff to get nfs shares in tmpfs to work properly. There may be issues with other file system types also.
Its ext4 on all machines. Relevant mount points are starred:
One thing I do see is that the mount from server2 is as nfs (as opposed to nfs4 from server1). But that may not be the reason as I just added a second client in the network (client2) with same configuration as client1. And I can mount on client2 without the nolock option:
I'll scrutiny if there is any difference in client1 and client2 settings for any further clue.
Meanwhile, if anyone has any other hints/ideas, please share.
It seems the issue stems from hosts.deny/allow configuration as AwesomeMachine had mentioned earlier.
client1 is firewall-ed to be accessed only via vpn. So I had this in hosts.deny
Code:
ALL: ALL
and in hosts.allow
Code:
sshd:xxx.yyy.
where all vpn connections get an ip xxx.yyy.aaa.bbb
client2 did not have this vpn firewall and if I remove the vpn restriction on client1, nfs mounts work!
Now the question is how can I best use NFS with vpn restrictions?
I found that this combination works:
Code:
$ cat /etc/hosts.deny
ALL: ALL
$ cat /etc/hosts.allow
sshd:xxx.yyy.
rpcbind:ALL
But this seems a little insecure to me. I was hoping to restrict NFS access to only vpn-restricted ips, i.e., xxx.yyy.aaa.bbb.
So I tried following combinations:
Code:
$ cat /etc/hosts.deny
ALL EXCEPT in.rpcbind: ALL
ALL EXCEPT in.portmap: ALL
$ cat /etc/hosts.allow
sshd:xxx.yyy.
rpcbind:ip.of.client.1
rpcbind:ip.of.server.1
portmap:ip.of.client.1
portmap:ip.of.server.1
But I still get the same error.
Any pointer on what I may be missing in the hosts.deny/hosts.allow files would be appreciated.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.