Não é possível montar o NFS a partir do Ubuntu 14.04.1 LTS no QNAP NAS

3

Note que esta é uma questão de postagem cruzada na comunidade NAS da QNAP aqui: link

Quaisquer comentários e sugestões, bem como indicações de informações relevantes são muito apreciados.

Não consigo montar o NFS do meu cliente NFS que executa o Ubuntu 14.04.1 (LTS) no meu servidor NFS (QNAP NAS). Meu ambiente é:

  • Servidor NFS: QNAP TS-669 Pro executando o firmware 4.1.0 (data: 2014/06/12)
  • Cliente NFS: ECS LIVA (um pequeno PC barebone) que executa o Ubuntu 14.04.1 LTS Desktop.
  • Os dois sistemas são conectados via Ethernet 1000Base-T e podem ser acessados por IP.
  • A resolução de nomes é feita pelo registro local (/ etc / hosts) e o comando hosts do host host-name retorna o endereço IP correto e consistente nos dois nós.
  • O serviço NFS está habilitado no servidor NFS e o direito de acesso NO_LIMIT é fornecido na pasta de compartilhamento específica, "/ nfs", na guia "Acesso ao host NFS" do aplicativo de configuração "Pastas compartilhadas": na verdade, pode confirmar que é o NFS mundial exportado através da emissão do comando "exportfs -rva" no NAS.
  • Como o Ubuntu (o cliente NFS) não instala pacotes cliente NFS por padrão, eu instalei explicitamente o pacote nfs-common como descrito aqui: Configurando o NFS HOW-TO ( link ); O pacote rpcbind parece estar instalado por padrão.

No cliente NFS, se eu executar o comando "montar -t nfs nas: / nfs / mnt" , ele fornecerá a saída "mount.nfs: Conexão expirada" depois de cinco ou 10 minutos depois. O mesmo resultado é retornado mesmo se eu especificar o protocolo NFS versão 3 com a opção -overs = 3 ao tentar montar o NFS. Além disso, o comando " showmount -e " lista os nomes exportados da pasta compartilhada NFS (diretório), mas também leva cinco ou 10 minutos para ser concluído.

No servidor NFS, o comando "exportfs -rva" retorna a seguinte mensagem de aviso, mas acredito que a mensagem não esteja relacionada ao problema (estou acessando o NAS via SSH neste código exmple):

[~] # exportfs -rva
exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/share/MD0_DATA/Public".
Assuming default behaviour ('no_subtree_check').   NOTE: this default has changed since nfs-utils version 1.0.x

exportfs: /etc/exports [2]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/share/MD0_DATA/nfs".
Assuming default behaviour ('no_subtree_check').   NOTE: this default has changed since nfs-utils version 1.0.x

exporting *:/share/MD0_DATA/nfs exporting *:/share/MD0_DATA/Public

No cliente NFS, o comando mount leva muito tempo (mais de cinco minutos) para ser concluído. Eu especifiquei a opção vers = 3, porque eu entendo QNAP não suporta NFS V4 por padrão e NFS V3 é suficiente minha exigência. Não importa se especifica ou não as opções tcp e / ou nolock (mesmo comportamento).

root@livak5:~# mount -t nfs -vvv -overs=3,tcp,nolock nas:/share/MD0_DATA/nfs /mnt
mount: fstab path: "/etc/fstab"
mount: mtab path:  "/etc/mtab"
mount: lock path:  "/etc/mtab~"
mount: temp path:  "/etc/mtab.tmp"
mount: UID:        0
mount: eUID:       0
mount: spec:  "nas:/share/MD0_DATA/nfs"
mount: node:  "/mnt"
mount: types: "nfs"
mount: opts:  "vers=3,tcp,nolock"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "nas:/share/MD0_DATA/nfs"
mount: external mount: argv[2] = "/mnt"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw,vers=3,tcp,nolock"
mount.nfs: timeout set for Sun Aug 24 11:24:44 2014
mount.nfs: trying text-based options 'vers=3,tcp,nolock,addr=192.168.11.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100005 vers 3 prot TCP port 41687
mount.nfs: mount(2): Connection timed out
mount.nfs: trying text-based options 'vers=3,tcp,nolock,addr=192.168.11.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100005 vers 3 prot TCP port 41687
mount.nfs: mount(2): Connection timed out
mount.nfs: trying text-based options 'vers=3,tcp,nolock,addr=192.168.11.50'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 192.168.11.50 prog 100005 vers 3 prot TCP port 41687
mount.nfs: mount(2): Connection timed out
mount.nfs: Connection timed out

No cliente NFS, o portmapper parece funcionando bem com a versão 2, 3 e 4 do NFS:

root@livak5:~# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  57148  status
    100024    1   tcp  52831  status

No servidor NFS, tentei verificar se o pormapper está sendo executado nele a partir do cliente NFS, já que ele não tem o comando rpcinfo instalado:

root@livak5:~# nc -zv nas 111
Connection to nas 111 port [tcp/sunrpc] succeeded!
root@livak5:~# rpcinfo -s nas
   program version(s) netid(s)                         service     owner
    100000  2,3,4     local,udp,tcp                    portmapper  superuser
    100011  2,1       tcp,udp                          rquotad     superuser
    100005  3,2,1     tcp,udp                          mountd      superuser
    100003  3,2       udp,tcp                          nfs         superuser
    100227  3,2       udp,tcp                          -           superuser
    100021  4,3,1     tcp,udp                          nlockmgr    superuser
    100024  1         tcp,udp                          status      superuser

O comando posterior ( rpcinfo ) leva muito tempo (mais de cinco minutos) para concluir o que replica a causa-raiz do problema, acredito. Por favor, note que nas duas portas TCP, 2049 e 41687, os processos daemon apropriados estão escutando no NAS. Posso confirmar este fato, pois o comando nc retorna instantaneamente no cliente NFS contra o NAS, conforme mostrado na seguinte saída:

root@livak5:~# nc -zv nas 2049
Connection to nas 2049 port [tcp/nfs] succeeded!
root@livak5:~# nc -zv nas 41687
Connection to nas 41687 port [tcp/*] succeeded!

Por incrível que pareça, eu posso montar a versão 3 do NFS no próprio NAS, como mostrado na seguinte saída (estou acessando o NAS via SSH neste exemplo de código):

[~] # mkdir /mnt2
[~] # mount -overs=3 nas:/share/MD0_DATA/public /mnt2
[~] # df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/ram0               154691    137854     16837  89% /
devtmpfs               1531580         4   1531576   0% /dev
tmpfs                    65536       160     65376   0% /tmp
/dev/md9                521684    126312    395372  24% /mnt/HDA_ROOT
/dev/md0             11622485880 410664920 11211296672   4% /share/MD0_DATA
/dev/md13               379888    259868    120020  68% /mnt/ext
tmpfs                    32768         0     32768   0% /.eaccelerator.tmp
nas:/share/MD0_DATA/public/11622485888 411189216 11211296672   4% /mnt2

Embora pareça que eu tenha algum tipo de problema de portas bloqueadas no NFS Client, mas parece que o Ubuntu 14.04.1 não habilita o ufw (firewall descomplicado, na verdade é um front-end do iptables) por padrão, como mostrado o seguinte documento da wiki: Firewall Descomplicado (de alguma forma, não consigo colocar o URL da wiki aqui). Posso confirmar nada bloqueado executando o comando no cliente NFS:

root@livak5:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
    
por suekichi5 24.08.2014 / 05:53

2 respostas

0

Acontece que a causa raiz do problema é o bug do firmware do Switch Ethernet que estou usando (NetGEAR GS116Ev2). Depois de atualizar o firmware para 2.0.1.17 a partir de 2.0.0.23, o problema desapareceu.

    
por suekichi5 28.08.2014 / 16:03
-1

Passei as noites recentes pesquisando o motivo dos problemas, comuns ao Seu (muito tempo para responder no showmount ou rpcinfo). Ele termina desativando o recurso de prevenção DoS de dois SWITCHES GERENCIADOS diferentes, que bloquearam o portmap nfs (silenciosamente, sem log). nfs impraticável usando novo switch gerenciado - não sei por quê - O DoS de dois switches ZyXel quebra o portmap

    
por coro 29.10.2014 / 16:44