mount.nfs: rpc.statd не работает, но требуется для удаленной блокировки

20592
RegedUser00x

Я пытаюсь смонтировать диск с удаленного компьютера, но я получаю эту ошибку:

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

Я использую Debian 7. Удаленный сервер работает под управлением Debian 5. Есть идеи, почему это происходит? Если я добавлю дополнительный аргумент, он будет работать, но проблема в том, что я хочу смонтировать его автоматически через autofs. Как ни странно, я могу монтировать диски с другого сервера (на котором работает Debian 7).

5

4 ответа на вопрос

8
Xavi Montero

Я получил ту же проблему и потому, что клиент пытался локально подключиться к своему собственному RPC.

Я должен был добавить 127.0.0.1к моей /etc/hosts.allowмашине клиента.

Для моей сессии, скопированной ниже, это вовлеченные данные:

  • guarra это имя клиентского компьютера.
  • 192.168.2.53сервер (названный, fluorно это имя здесь не используется).
  • /files это экспортированный ресурс с сервера.
  • /files/fluor это место для его установки.

Предварительная модификация сеанса оболочки:

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#

Я изменил файл и получил это:

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#

После добавления локального IP-адреса к клиенту он может использовать собственный rpc, как вы видите, сообщение об ошибке исчезло, и я мог правильно смонтировать удаленный общий ресурс.

Спасибо, добавление 127.0.0.1 в hosts.allow для службы rpcbind решило эту проблему для меня в Ubuntu 16.04, теперь autofs автоматически монтирует общие ресурсы nfs. w0utert 7 лет назад 1
1
RegedUser00x

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

1
anarcat

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
0
smooker

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.

Я не могу найти этот файл в моей системе, но я установил значение NEED_STATD как да, так и нет в /etc/init.d/nfs-common, и это не помогает. RegedUser00x 10 лет назад 0
Это плохой ответ, потому что 1) я подозреваю, что это только для Arch Linux и 2) он не предоставляет пример полного кода (т. Е. `NEED_STATD = yes` или` NEED_STATD yes` puk 10 лет назад 0

Похожие вопросы