Esse problema está basicamente me deixando louco neste momento. Eu tenho um servidor Ubuntu 16.04 NFS que estava funcionando bem com esta configuração:
/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98 /data2 xfs rw,relatime 0 0
/data2 /srv/nfs/cryodata none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
e
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Tudo isso tem funcionado bem há meses no único cliente nfs que usa essa configuração até agora, usando essas entradas /etc/fstab do lado do cliente:
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
Contudo, como este é um servidor de armazenamento muito grande, foi decidido que ele precisa acomodar vários laboratórios. Então, movi todo o material que estava espalhado pela partição /data2 para um subdiretório /data2/cryodata e atualizei /etc/fstab no servidor e /etc/exports da seguinte forma:
/etc/fstab:
...
/data2/cryodata /srv/nfs/cryodata none defaults,bind 0 0
/data2/xray /srv/nfs/xray none defaults,bind 0 0
/data2/EM /srv/nfs/EM none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
e
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Isso simplesmente não funciona! Quando tento montar a nova montagem no cliente usando a mesma entrada /etc/fstab do cliente:
{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
.
# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...
O /usr/local continua sendo montado sem problemas. A primeira vez que tentei isso, esqueci de desexportar/exportar os sistemas de arquivos exportfs -varantes de fazer alterações, mas desde então mudei de um lado para o outro, tomando cuidado para desexportar e desmontar tudo, com várias reinicializações de servidor entre eles. A montagem original de uma montagem de ligação de toda a partição sempre funciona, e a montagem de ligação de um subdiretório falha sempre com a mensagem de identificador nfs obsoleto. Tentei habilitar outros clientes NFS que nunca montaram essas partições e obtiveram exatamente a mesma mensagem de erro: neste caso, é definitivamente um problema no servidor. Eu verifiquei /var/lib/nfs/etab para ter certeza de que foi limpo entre tentativas de montagem, etc.
Achei que a técnica de montagem vinculada em um diretório raiz do servidor NFS resolvesse todos esses tipos de problemas, mas aparentemente não? O estranho é que /usr/local é um subdiretório de outra partição e sempre monta bem. Está em um ext3 md raid 1, embora eu não consiga imaginar que isso importe.
Passei horas nisso e quase quebrei o Google procurando uma solução sem sucesso.
Responder1
Observe que estou exportando apenas sistemas de arquivos montados em bind. Esta seção doexportaçõesA página de manual é relevante:
fsid=num|root|uuid
O NFS precisa ser capaz de identificar cada sistema de arquivos que exporta. Normalmente ele usará um UUID para o sistema de arquivos (se o sistema de arquivos tiver tal coisa) ou o número do dispositivo que contém o sistema de arquivos (se o sistema de arquivos estiver armazenado no dispositivo).
Minha suposição errada foi que os sistemas de arquivos montados em bind possuem algum tipo de UUID que o NFS pode usar automaticamente; e suposição reforçada pelo fato de que ambas as exportações vinculadas funcionaram bem sem um fsid:
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
No entanto, isso resulta em um comportamento inconsistente. Eu adicionei um /opt montado em ligação:
/etc/fstab:
/data1/opt /srv/nfs/opt none defaults,bind 0 0
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,no_subtree_check)
resultou em comportamento inconsistente; ou seja, poderia alterar o IP de exportação e montar em uma máquina, mas obter permissão negada em outra. A solução foi adicionar um fsid:
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,fsid=20,no_subtree_check)
Portanto, a solução é sempre adicionar um fsid para exportar sistemas de arquivos montados em bind.