O servidor NFS v4 está causando manipulação de arquivos obsoletos, mas apenas quando a montagem de ligação é um subdiretório

Question

Este problema está basicamente me deixando louco, neste momento. Eu tenho um servidor NFS 16.04 Ubuntu 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 por meses no único cliente nfs usando esta configuração até agora usando estas 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

No entanto, como esse é um servidor de armazenamento muito grande, foi decidido que ele precisa acomodar vários laboratórios. Então, movi todas as coisas que estavam espalhadas pela partição / data2 para um subdiretório / data2 / cryodata e atualizei o / 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 do cliente / etc / fstab:

{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 a montar sem problemas. A primeira vez que tentei isso, esqueci de não exportar / exportar os sistemas de arquivos usando exportfs -var antes de fazer alterações, mas desde então mudei para frente e para trás, tomando cuidado para não exportar e desmontar tudo, com várias reinicializações do servidor entre elas. 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 com a mensagem obsoleta de identificador do nfs sempre. Eu tentei habilitar outros clientes nfs que nunca montaram essas partições e obter exatamente a mesma mensagem de erro: neste caso, é definitivamente um problema do lado do servidor. Eu verifiquei / var / lib / nfs / etab para ter certeza de que está limpo entre as tentativas de montagem, etc.

Eu achei que a técnica de vincular a montagem em um diretório raiz do servidor nfs resolveu todos esses tipos de problemas, mas aparentemente não? O mais estranho é que o / usr / local é um subdiretório de outra partição, e sempre monta bem. Está em um ext3 md raid 1, embora eu não possa imaginar isso importa.

Passei horas nisto e quase quebrei o google em busca de uma solução sem sucesso.

    

Answer 1

Observe que estou exportando apenas sistemas de arquivos montados em bind. Esta seção da página do manual exporta é relevante:

fsid=num|root|uuid

NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device).

Minha suposição errônea é que sistemas de arquivos montados por 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 montadas no bind funcionavam 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 comportamento inconsistente. Eu adicionei um bind montado / opt:

/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; isto é, 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.