mount.nfs: rpc.statd não está em execução, mas é necessário para o bloqueio remoto

Question

Estou tentando montar um disco de um computador remoto, mas recebo este erro:

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

Estou usando a Debian 7. O servidor remoto está executando o Debian 5. Alguma idéia de por que isso acontece? Se eu adicionar o argumento extra, ele funciona, mas o problema é que eu quero montá-lo automaticamente via autofs. Estranhamente eu consigo montar discos de outro servidor (que roda Debian 7).

    

Answer 1

Eu adicionei o argumento nolock no arquivo /etc/auto.rat e agora ele também funciona com o autofs.

    

Answer 2

Eu tenho o mesmo problema e foi porque o cliente tentou se conectar localmente ao seu próprio rpc.

Eu tive que adicionar 127.0.0.1 ao meu /etc/hosts.allow na máquina do cliente.

Para minha sessão copiada abaixo, esses são os dados envolvidos:

• guarra é o nome da máquina do cliente.
• 192.168.2.53 do servidor (chamado fluor , mas esse nome não é usado aqui).
• /files é o compartilhamento exportado do servidor.
• /files/fluor é o destino para montá-lo.

Uma pré-modificação da sessão do shell:

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#

Eu modifiquei o arquivo e recebi isso:

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#

Depois de adicionar o IP local ao cliente, ele pode usar seu próprio rpc, como você pode ver, a mensagem de erro desapareceu e eu pude montar o compartilhamento remoto corretamente.

    

Answer 3

Eu também tive problemas com servidores onde a interface de loopback foi removida. Nesse caso, o tráfego tenta passar para a interface normal (digamos, eth0 ) e expira.

A solução nesse caso é restaurar a interface de loopback, que provavelmente se parece com algo assim (Debian Wheezy 7.6):

# The loopback network interface
auto lo
iface lo inet loopback

    

Answer 4

link

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