15

I am trying to mount a disk from a remote computer but I get this error:

root@sidibalkan:~# mount -t nfs rat:/develop /mnt
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

I am running Debian 7. The remote server is running Debian 5. Any idea why this happens? If I add the extra argument it works but the problem is that I want to mount it automatically via autofs. Strangely enough I can mount disks from another server (which runs Debian 7).

RegedUser00x
  • 511
  • 3
  • 7
  • 23

6 Answers6

15
systemctl start rpc-statd

or 

service rpcbind start
service nfs-common start

then your NFS mounts will work.

mati kepa
  • 289
9

I got the same problem and was because the client tried to connect locally to its own rpc.

I had to add 127.0.0.1 to my /etc/hosts.allow in the client machine.

For my session copied below, those are the involved data:

  • guarra is the name of the client machine.
  • 192.168.2.53 the server (named fluor but this name is not used here).
  • /files is the exported share from the server.
  • /files/fluor is the destination to mount it on.

A shell session pre-modification:

root@guarra:/files# cat /etc/hosts.allow
rpcbind : 192.168.2.0/24
root@guarra:/files# mount 192.168.2.53:/files fluor/
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@guarra:/files#

I modified the file and got this:

root@guarra:/files# cat /etc/hosts.allow
rpcbind : 192.168.2.0/24 127.0.0.1
root@guarra:/files# mount 192.168.2.53:/files fluor/
root@guarra:/files#

After adding the local IP to the client, it could use it's own rpc, as you can see, the error message disappeared and I could mount the remote share properly.

Xavi Montero
  • 703
2

I added the nolock argument in the /etc/auto.rat file and now it works with autofs too.

RegedUser00x
  • 511
  • 3
  • 7
  • 23
1

I have also had problems with servers where the loopback interface was removed. In that case, traffic tries to go over to the regular (say eth0) interface and times out.

The solution in that case is to restore the loopback interface, which probably looks something like this (Debian Wheezy 7.6):

# The loopback network interface
auto lo
iface lo inet loopback
anarcat
  • 480
0

start rpcbind and nfslock services.reference

/etc/init.d/rpcbind start
/etc/init.d/nfslock start
Vijay S B
  • 333
  • 2
  • 5
0

https://wiki.archlinux.org/index.php/NFS_Troubleshooting

To fix this, you need to change the "NEED_STATD" value in /etc/conf.d/nfs-common.conf to YES.

smooker
  • 19