Declaração do problema (observe que este problema foi resolvido, mas há uma pergunta sobre por que a solução funciona)
O servidor NFS é o Ubuntu 16.04.4 LTS. Os clientes são uma mistura de Ubuntu 16.04.4 LTS e CentOS 6.10 e 7.
O servidor NFS está funcionando bem há meses, e uma exportação em particular estava atendendo vários clientes para seus backups. O diretório do servidor NFS ficou assim:
/mnt/backups/client1
/mnt/backups/client2
/mnt/backups/client3
/mnt/backups/client4
O /etc/exports continha:
/mnt/backups 1.2.3.0/24(rw,sync,no_subtree_check)
O cliente monta o servidor nfs apenas durante um backup e, em seguida, desmonta o backup quando ele é concluído.
Isso estava funcionando bem, no entanto, foi determinado que os clientes não deveriam poder ver uns aos outros no diretório /mnt/backups. Cada cliente está usando o mesmo uid/gid de backup. Portanto, foi tomada a decisão de separar os diretórios através do uso do arquivo /etc/exports.
Para esse fim, o servidor NFS foi interrompido e o /etc/exports foi modificado para conter:
/mnt/backups/client1 1.2.3.21(rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(rw,sync,no_subtree_check)
Lembre-se, o cliente só monta o servidor NFS quando está fazendo um backup (às 4h). No servidor, o serviço NFS foi reiniciado e as exportações são verificadas com exportfs, parece bom.
OK, testando client1:
mount nfserver:/mnt/backups/client1 /mnt/client1
funciona bem, no entanto, qualquer ação em /mnt/client1 resulta em:
cannot open directory /mnt/client1/: Stale file handle
Ações tomadas para resolver (que não funcionaram) : Reiniciando o NFS no servidor. Reiniciando cliente. lsof |grep /mnt no cliente e no servidor para ver se algum programa estava mantendo os arquivos abertos. Verificações de permissões no servidor/cliente. Novamente, alternar o NFS /etc/exports de volta para o arquivo antigo e montar o servidor nfs a partir do cliente funciona. Voltar para o método "novo" não funciona.
Depois de muito ranger de dentes, páginas de manual e STFW apenas para encontrar respostas como "reiniciar o NFS", lembrei que tive esse problema anos atrás e, por algum motivo, o fsid teve algo a ver com a solução. Depois de ler as páginas man, o seguinte foi adicionado ao arquivo /etc/exports do servidor NFS:
/mnt/backups/client1 1.2.3.21(fsid=101,rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(fsid=102,rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(fsid=103,rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(fsid=104,rw,sync,no_subtree_check)
Novamente, após essa ação, a única coisa executada foi um exportfs -ra no servidor.
Agora todos os clientes podem montar as exportações do servidor nfs e todos funcionam.
Por que isso é uma solução?
Devemos usar fsid em todas as exportações?
Ler uma página de manual como esta não parece explicar claramente por que o fsid é uma solução. Eu tinha uma ideia de que poderia ser que a montagem obsoleta fosse algum tipo de manipulador de arquivos NFS no lado do cliente (ou talvez no lado do servidor), mas para isso persistir após uma reinicialização pareceria estranho.
Resumindo, o fsid é a maneira como o cliente e o servidor identificam uma exportação depois de montada.
Como a página man indica, o fsid será derivado do sistema de arquivos subjacente, se não for especificado.
As quatro exportações têm o mesmo fsid, então é possível que quando o cliente1 estiver perguntando sobre os arquivos de sua montagem, o servidor pense que está tentando acessar a exportação do cliente4 (assumindo que está mantendo apenas a última ocorrência do mesmo fsid).
Acho que existem algumas maneiras de validar essa hipótese, por exemplo, verificando se um (e apenas um) dos 4 clientes funcionará. Também mantendo apenas a exportação client1, sem as outras 3, e confirmando client1 funcionará então.
Veja também esta resposta para uma maneira de consultar o fsid de um cliente, usando o
mountpoint -dcomando, que você pode usar nos 4 clientes para confirmar que as 4 montagens têm o mesmo fsid.Por que isso é uma solução?
Porque com fsids distintos, as exportações parecerão distintas para o servidor NFS, portanto, corresponderá adequadamente aos acessos do cliente às suas montagens correspondentes.
Devemos usar fsid em todas as exportações?
Sim, acho que é uma boa prática, garante que você manterá o controle e as alterações nos dispositivos de armazenamento subjacentes e as exportações não afetarão seus clientes.
(No meu caso, lembro-me de adotá-lo, pois alguns dos meus servidores NFS com discos em uma SAN às vezes examinavam os discos em uma ordem diferente, portanto, após uma reinicialização, /dev/sdh de repente se tornava /dev/sdj. A montagem usando rótulos garantiu que seria montado no local correto, mas o fsid mudaria e os clientes se perderiam. Isso é antes da onipresença dos UUIDs, que aparentemente agora são suportados e são, claro, uma solução muito melhor para isso, que não quebraria quando os discos são verificados em uma ordem diferente. Mas, ainda assim, especificar o fsid explicitamente não é uma má ideia, permite manter o controle total.)