13

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
  • 491
  • 2
  • 7
  • 22

6 Answers6

13
systemctl start rpc-statd

or 

service rpcbind start
service nfs-common start

then your NFS mounts will work.

mati kepa
  • 259
  • 2
  • 5
  • 1
    Although I answered this question 7 years ago, today I was trying to use a client inside an ubuntu inside a docker, and this double `service` thing made it work. I just had to run those lines inside the docker container before doing the mount. – Xavi Montero May 02 '21 at 22:08
  • I was trying to connect to an Ubuntu 20.04 VM. I set up an NFS mount on VM, then on the Linux guest ran `systemctl start rcp-statd` and viola! I was able to connect to the VM from my Mac host – Kearney Taaffe Aug 24 '21 at 15:01
  • systemctl start rpc-statd worked for me, I was having some lockd not responding errors – Alejandro T Sep 10 '21 at 17:22
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
  • 523
  • 6
  • 19
  • 1
    Thanks, adding 127.0.0.1 to hosts.allow for the rpcbind service solved this problem for me on Ubuntu 16.04, autofs now mounts nfs shares automatically. – w0utert Feb 04 '17 at 12:14
2

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

RegedUser00x
  • 491
  • 2
  • 7
  • 22
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
  • 411
  • 4
  • 13
0

start rpcbind and nfslock services.reference

/etc/init.d/rpcbind start
/etc/init.d/nfslock start
Vijay S B
  • 283
  • 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
  • 2
  • I can't find this file on my system but I set the value of NEED_STATD to both yes and no in /etc/init.d/nfs-common and it doesn't help. – RegedUser00x Oct 11 '13 at 07:45
  • 1
    This is a bad answer because 1) I suspect this is for only Arch Linux and 2) it doesn't provide an example of the full code (ie. `NEED_STATD=yes` or `NEED_STATD yes` – puk Nov 15 '13 at 05:35