O servidor NFS v4 está causando manipulação de arquivo obsoleta, mas somente quando a montagem de ligação é um subdiretório

O servidor NFS v4 está causando manipulação de arquivo obsoleta, mas somente quando a montagem de ligação é um subdiretório

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.

informação relacionada