Não é possível montar o volume do nfs - tempo limite

Question

Eu tenho uma exportação NFSv3 de um servidor de arquivos Linux que costumava montar bem. O servidor de arquivos teve que ir para manutenção de hardware. Depois de recuperar o servidor, o cliente Linux não pode mais montar a exportação do nfs.

Nenhuma configuração foi alterada no servidor ou no cliente. Eu fiz uma atualização de software e reiniciei o cliente depois que a primeira montagem falhou, mas isso não ajudou.

[root@client ~]# showmount -e ark
Export list for ark:
/mnt/bigraid *

[root@client ~]# mount -t nfs ark:/mnt/bigraid raid

Ele apenas trava neste momento. Em outro terminal ...

[root@client ~]# dmesg | tail
[ 2526.676437] nfs: server ark not responding, timed out
[ 2529.183107] nfs: server ark not responding, timed out
[ 2531.689778] nfs: server ark not responding, timed out
[ 2538.196432] nfs: server ark not responding, timed out
[ 2540.703107] nfs: server ark not responding, timed out
[ 2543.209767] nfs: server ark not responding, timed out
[ 2545.716436] nfs: server ark not responding, timed out
[ 2548.223098] nfs: server ark not responding, timed out
[ 2550.729775] nfs: server ark not responding, timed out
[ 2557.236435] nfs: server ark not responding, timed out

... OK, mas pude ver as exportações com showmount ...

[root@client ~]# ping ark
PING ark.homebase (10.10.10.2) 56(84) bytes of data.
64 bytes from ark.homebase (10.10.10.2): icmp_seq=1 ttl=64 time=0.067 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=3 ttl=64 time=0.048 ms
64 bytes from ark.homebase (10.10.10.2): icmp_seq=4 ttl=64 time=0.042 ms
^C
--- ark.homebase ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms

Então eu não entendi.

O servidor está executando o OpenSUSE. Assegurei que o firewall estava desligado (não que ele estivesse ligado) e que a conectividade de rede parece boa.

ark:/etc # cat exports
/mnt/bigraid    *(rw,root_squash,insecure,no_subtree_check,sync)

Edit: aqui está a lista de portas RPC em uso

ark:/etc/init.d # rpcinfo -p
program vers proto   port
100000    2   tcp    111  portmapper
100005    1   udp  37599  mountd
100005    1   tcp  33880  mountd
100005    2   udp  37599  mountd
100005    2   tcp  33880  mountd
100005    3   udp  37599  mountd
100005    3   tcp  33880  mountd
100024    1   udp  49522  status
100024    1   tcp  41314  status
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100021    1   udp  51887  nlockmgr
100021    3   udp  51887  nlockmgr
100021    4   udp  51887  nlockmgr
100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100021    1   tcp  49804  nlockmgr
100021    3   tcp  49804  nlockmgr
100021    4   tcp  49804  nlockmgr
100000    2   udp    111  portmapper

Editar 2: Tem algumas informações do tcpdump

(Editar 3: saída tcpdump removida, pois pode não ser relevante.)

Eu não estou familiarizado com o que uma negociação nfs adequada parece. Eu também joguei um arquivo pcap se você quiser ver os segmentos de dados. É no arquivador

Editar 3: Eu posso estar acessando este problema

Eu estava seguindo o conselho da @ CIA abaixo e fiz isso:

ark:/etc/init.d #  ./nfsserver stop
Shutting down kernel based NFS server: nfsd statd mountd idmapd       done
ark:/etc/init.d # ./portmap stop
Shutting down RPC portmap daemon                                      done
ark:/etc/init.d # ./portmap start
Starting RPC portmap daemon                                           done
ark:/etc/init.d # ./nfsserver start
Starting kernel based NFS server: idmapdexportfs: Warning: /mnt/bigraid does not support NFS export.
 mountd statd nfsd sm-notify                                          done

Apesar do aviso, a exportação agora parece montável.

    

Answer 1

Portanto, o NFS é estranho no fato de ele precisar que o portmapper esteja rodando, então ele pode mapear uma porta específica para uma porta RPC. (Eu acho que não é estranho. É apenas o jeito que funciona.) Se o NFS está ativo antes do portmapper, o NFS não sabe como rotear os pedidos, porque ele verifica o portmapper para isso no início do processo. Se o portmapper não estiver ativo antes do NFS, o NFS não saberá como mapear a porta para o rpc.

Aqui está mais documentação sobre o processo (embora seja para o CentOS, ainda é relevante): link

Quanto à sua nova mensagem de erro, reinicie a caixa com a qual você está montando e remonte para ver se o erro retorna.

    

Answer 2

tcpdump -i $LAN_IF -n host 10.10.10.2

deve mostrar a você qual dos componentes do NFS falha.

    

Answer 3

Bem, eu costumava receber o mesmo erro. Percebi que a única razão para haver um tempo limite é porque a conexão não foi estabelecida corretamente. Indo mais fundo no problema, eu verifiquei o meu firewall, e o maldito serviço NFS4 foi bloqueado!

Solução: - Use o comando abaixo para definir suas configurações de firewall e adicionar * ao lado do serviço NFS4 para ativá-lo.

$ sudo system-config-firewall-tui

    

Answer 4

Ative as seguintes portas TCP e UDP para os clientes acessarem o compartilhamento do nfs no servidor.

Para o NFS3 tcp: 111,662,875,892,2020,2049,32803
udp: 111,2049,32769

Para NFS4

tcp: 111,2049 udp: 111,2049

Editar: tente telnetar as portas acima do cliente nfs

    

Answer 5

Se você tem firewall baseado em host e usa o nfs, confira:

link

Você pode especificar quais portas seus daemons estão usando, então eles não estão sendo atribuídos aleatoriamente.