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

Question

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

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).

Answer 1

Я получил ту же проблему и потому, что клиент пытался локально подключиться к своему собственному 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, как вы видите, сообщение об ошибке исчезло, и я мог правильно смонтировать удаленный общий ресурс.

Answer 2

Я добавил аргумент nolock в файл /etc/auto.rat, и теперь он работает и с autofs.

Answer 3

У меня также были проблемы с серверами, на которых был удален петлевой интерфейс. В этом случае трафик пытается перейти на обычный (скажем, eth0) интерфейс и время ожидания истекает.

Решение в этом случае заключается в восстановлении интерфейса обратной связи, который, вероятно, выглядит примерно так (Debian Wheezy 7.6):

# The loopback network interface
auto lo
iface lo inet loopback

Answer 4

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

Чтобы это исправить, вам нужно изменить значение "NEED_STATD" в /etc/conf.d/nfs-common.conf на YES.