FATOS
Um arquivo / etc / exports que funciona anteriormente, rodando perfeitamente no Debian, não funciona como esperado no Ubuntu. Eu posso exportar um diretório de nível superior; os clientes podem montá-lo e ver um nível de diretório abaixo; mas eles não conseguem ver outros subdiretórios e não podem montar subdiretórios.
DISCUSSÃO
Primeiro, algo que funciona um pouco:
/archive 192.168.0.0/255.255.255.0(fsid=root,crossmnt,rw,sync,no_root_squash,no_subtree_check)
O fsid = root é obrigatório, aparentemente - não é assim no Debian - e crossmnt está lá para testes.
Eu posso montar / arquivar em um cliente. Eu posso descer para / archive / dir1. No entanto, quando os clientes tentam ler o diretório / archive / dir1, o diretório aparece como vazio.
Em seguida, experimento uma versão de duas linhas de / etc / exports:
/archive 192.168.0.0/255.255.255.0(fsid=root,crossmnt,rw,sync,no_root_squash,no_subtree_check)
/archive/dir1/dir2/dir3 192.168.0.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check)
A primeira linha é igual à anterior e a segunda linha exporta um subdiretório como uma entidade separada. Novamente, isso funciona bem quando exportado do Debian.
Neste ponto, qualquer tentativa de montar / archive / dir1 / dir2 / dir3 falhará. Em um cliente Debian, o cliente tenta usar o NFS versão 4.2, reclamações de um identificador de arquivo antigo, retorna à versão 3 e roda na versão 3 indefinidamente.
Em um cliente Ubuntu, uma tentativa de montagem falha com "Manipulação de arquivo obsoleto" usando o NFS versão 4; volta à versão 3 e alterna entre os protocolos 6 e 17; e eventualmente falha.
Por favor, note:
* Todos os clientes estão por trás do mesmo firewall
* Nenhuma máquina está executando um firewall interno (por exemplo, ufw está desativado ou desativado)
rpcinfo no servidor:
# 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
100005 1 udp 51505 mountd
100005 1 tcp 33248 mountd
100005 2 udp 59490 mountd
100005 2 tcp 46113 mountd
100005 3 udp 59750 mountd
100005 3 tcp 38367 mountd
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 55501 nlockmgr
100021 3 udp 55501 nlockmgr
100021 4 udp 55501 nlockmgr
100021 1 tcp 37597 nlockmgr
100021 3 tcp 37597 nlockmgr
100021 4 tcp 37597 nlockmgr
rpcinfo no cliente:
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
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 56523 nlockmgr
100021 3 udp 56523 nlockmgr
100021 4 udp 56523 nlockmgr
100021 1 tcp 37425 nlockmgr
100021 3 tcp 37425 nlockmgr
100021 4 tcp 37425 nlockmgr
100024 1 udp 39290 status
100024 1 tcp 37851 status
100005 1 udp 52528 mountd
100005 1 tcp 43547 mountd
100005 2 udp 36593 mountd
100005 2 tcp 34609 mountd
100005 3 udp 42349 mountd
100005 3 tcp 45613 mountd
Finalmente,
RPCMOUNTDOPTS="--manage-gids"
em / etc / default / nfs-kernel-server
EDITAR
Um possível sintoma é que / var / lib / nfs / rmtab não está atualizado. Espero que quando o nfs-kernel-server for interrompido, o rmtab seja atualizado; ou quando eu não exportar os sistemas de arquivos (exportfs -ua); ou quando desmonto no cliente. Em vez disso, o rmtab continua a manter as informações antigas.
AÇÕES
Gostaria de sugestões sobre como depurar este problema.
EDIT 2
Mais alguns pontos:
- Eu verifiquei as ACLs (nenhuma configuração) e as permissões de arquivo, e elas parecem estar corretas.
- Mesmo depois de um desligamento a frio do cliente e do servidor, feito por outros motivos, ainda recebo erros de "manuseio incorreto do arquivo".
-
Se eu ativar o rpcdebug para procurar o NFS proc, vejo uma reclamação sobre
nenhum caminho de retorno de chamada para o cliente Linux NFSv4.2
mas esse erro não aparece para, por exemplo, clientes MacOS ou Ubuntu.
-
Eu experimentei o / etc / exports absolutamente minimalista, mas nenhum funciona. Por exemplo,
/ alguma coisa * (sync, no_subtree_check)
não funciona.
Resumo: este problema permanece intratável, e IMO não é um problema de permissões simples - a menos que eu esteja perdendo uma configuração em algum lugar, ou até mesmo um programa inteiro ou arquivo de configuração.