Quando tento acessar um diretório que é montado em cruz no servidor nfs, o resultado é um erro "Operação não permitida", a menos que o root tenha acessado o diretório recentemente. Se o diretório não for tocado para o período de tempo limite, os usuários não poderão acessá-lo novamente até que a raiz tenha.
Eu tenho um servidor nfs que eu uso para mídia AV, servindo páginas da web e assim por diante. Seu nome é hamlet, executando debian e possui partições (LVM) para / export / web e outras. O cliente Xenial não pode atravessar a hierarquia de diretórios exportada, embora outros clientes possam.
No servidor:
Linux hamlet 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686
nick@hamlet:~$ cat /etc/exports
/export 172.17.0.0/255.255.0.0(rw,sync,crossmnt,no_subtree_check)
/export/web 172.17.0.0/255.255.0.0(rw,sync,nohide,no_subtree_check)
(Eu entendo que o nohide deve ser desnecessário, mas removê-lo não corrige o erro)
Na máquina desktop do Xenial, tenho este servidor montado em directory / auto:
nick@polonius:~$ uname -a
Linux polonius 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:06:14 UTC 2016 i686 i686 i686 GNU/Linux
nick@polonius:~$ cat /etc/auto.auto
# Mount exported directories from Hamlet under /auto
hamlet -sec=sys,nfsvers=3,noacl 172.17.1.5:/export
e em /etc/auto.master eu tenho a linha
/auto /etc/auto.auto
O problema é que, embora o diretório montado automaticamente de nível superior apareça, não é possível mudar para o diretório montado em cruz no servidor como um usuário comum.
Eu também tenho um laptop Debian com configuração idêntica . Este laptop não tem esse problema. Mas na máquina Ubuntu:
nick@polonius:~$ ls /auto
nick@polonius:~$ ls /auto/hamlet
archive children ebooks iPlayer media photos web
nick@polonius:~$ ls /auto/hamlet/web
ls: cannot open directory '/auto/hamlet/web': Operation not permitted
nick@polonius:~$ sudo ls /auto/hamlet/web
[sudo] password for nick:
htdocs lost+found mail mail_secrets.php Thunderbird_Archives
nick@polonius:~$ ls /auto/hamlet/web
htdocs lost+found mail mail_secrets.php Thunderbird_Archives
Em um laptop debain:
nick@ariel:~$ uname -a
Linux ariel 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64 GNU/Linux
nick@ariel:~$ ls /auto
nick@ariel:~$ ls /auto/hamlet
archive children ebooks iPlayer media photos web
nick@ariel:~$ ls /auto/hamlet/web
htdocs lost+found mail mail_secrets.php Thunderbird_Archives
Se eu executar o montador automático no terminal com -f -v, ele não relatará nenhum problema. Além disso, quando o root acessou o subdiretório fazendo com que ele apareça, ele possui as permissões corretas.
nick@polonius:~$ sudo ls /auto/hamlet/web
htdocs lost+found mail mail_secrets.php Thunderbird_Archives
nick@polonius:~$ touch /auto/hamlet/web/thing
nick@polonius:~$ ls -l /auto/hamlet/web/thing
-rw-rw-r-- 1 nick nick 0 Jul 24 13:13 /auto/hamlet/web/thing
nick@polonius:~$ rm /auto/hamlet/web/thing
nick@polonius:~$
Aposto que isso é minha culpa, mas não tenho ideia do que trocar na máquina Ubuntu para que funcione como deveria. O cliente Ubuntu estava trabalhando até aproximadamente uma semana atrás, então isso pode ser uma regressão.
Sugestões?
A reversão para construir 28 do kernel 4.4.0 faz com que o problema seja encerrado. Especificamente, Linux 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:08:35 UTC 2016 i686
Concluo que há uma regressão entre os builds 28 e 31, o que faz com que o automounter funcione mal, a menos que alguém consiga ver algo errado em meus arquivos de configuração (ou seja, estou chamando de bug, você pode achar que é um recurso: )
Eu tenho uma configuração similar: o servidor de arquivos Debian 8 vários clientes Ubuntu / Kubuntu. A configuração do NFS no servidor de arquivos também é comparável. A configuração está funcionando há meses, mas em um determinado momento ela começou a falhar em todos os clientes. Eu não percebi que as atualizações são a causa. Eu tenho lutado por algumas semanas (ligado e desligado) para encontrar um cliente estava trabalhando novamente. Atualizações onde aplicado em todos os clientes. Comparando as configurações, não consegui encontrar nenhuma diferença. Comparando “uname -a”: Cliente não funcional: “Linux xxxx-pc 4.4.0-31-genérico # 50-Ubuntu SMP Qua 13 de julho 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux”
Cliente de trabalho: "Linux xxxx-desktop 4.4.0-33-genérico # 52-Ubuntu SMP Sex Jul 22 19:16:44 UTC 2016 x86_64 x86_64 x86_64 GNU / L inux "
Acontece que no cliente em funcionamento eu estava usando atualizações “xenial-proposed” que atualizam o kernel. Carregar o kernel 4.4.0-33 em nenhum cliente em funcionamento resolve o problema.