Partição criptografada de exportação do NFS v4. Montagens de cliente dir vazio

Question

Eu tenho um disco rígido criptografado no meu servidor Lan. Foi criptografado usando luks / dm-crypt. O servidor tem um NFS v4 em execução para compartilhar arquivos no Lan. Funciona, exceto pelo disco rígido criptografado USB. Se o cliente monta os compartilhamentos em seu sistema de arquivos, ele encontra uma pasta vazia onde os arquivos descriptografados devem estar.

Esta é a configuração:

Como o servidor monta a partição luks :

sudo cryptsetup luksOpen /dev/sdb1 data1
sudo mount /dev/mapper/data1 /exports/user1/data1

Descriptografar e montar a unidade no servidor funciona bem. Se eu for para /exports/user1/data1 , obtenho os arquivos descriptografados.

As exportações NFS :

/exports            192.168.178.20(rw,sync,fsid=0,no_subtree_check,root_squash) 192.168.178.21(rw,sync,fsid=0,no_subtree_check,root_squash)
/exports/user1      192.168.178.20(rw,sync,no_subtree_check,root_squash) 192.168.178.21(rw,sync,no_subtree_check,root_squash)

Assim, a unidade USB descriptografada é montada diretamente nas exportações NFS em /exports/user1/data1

E é assim que o cliente monta a pasta compartilhada :

sudo mount.nfs4 192.168.178.10:/ /fs_data -o soft,intr,rsize=32768,wsize=32768

Agora, se o cliente monta as exportações do servidor em seu sistema de arquivos, ele encontra a pasta 'data1' vazia.

Há algo que esteja faltando?

Atualização:

Graças a Gilles excelente resposta , consegui que funcionasse. Eu tentei evitar crossmnt e nohide para não correr em eventuais problemas de inode . Isso é o que eu uso agora:

/ etc / exports

/exports/user1           192.168.178.20(rw,sync,fsid=0,crossmnt,no_subtree_check)
/exports/user1/data1     192.168.178.20(rw,sync,no_subtree_check)

comando do cliente para montar data1 :

sudo mount.nfs4 192.168.178.10:/data1 /fs_data -o soft,intr,rsize=32768,wsize=32768

    

Answer 1

Com o servidor NFS do kernel Linux, se você exportar uma árvore de diretórios, isso não inclui nenhum sistema de arquivos montado nessa árvore. Veja a descrição da opção nohide na página exports(5) man .

Você precisa exportar o sistema de arquivos montado explicitamente, ou seja, você precisa de uma linha separada em exports para /exports/user1/data1 . Além disso, você precisará (re) iniciar o servidor NFS após montar /exports/user1/data1 .

No lado do cliente, você precisa montar /fs_data/data1 separadamente. Conforme discutido na página exports man, você pode evitar isso incluindo a opção nohide em /exports/users1/data1 ou a opção crossmnt em /exports/users1 , mas isso pode causar problemas porque o cliente verá arquivos com o/fs_data/foo mesmo número de inode no que parece ser o mesmo sistema de arquivos. Isso pode, por exemplo, levar um programa de cópia ou arquivamento de arquivos a omitir arquivos porque acha que já foi feito backup deles (se o programa tiver visto /fs_data/data1/bar com inode 42, ele achará que o arquivo não relacionado %code% with inode 42 no que parece ser o mesmo sistema de arquivos - mas na verdade não é - é o mesmo arquivo).

    

Answer 2

Eu não posso comentar por falta de pontos, então eu vou adicionar que eu não tive que reiniciar o servidor nfs depois de adicionar o sistema de arquivos adicional para / etc / exports, isso seria uma dor desde que eu uso o kernel nfs , em vez disso, eu só preciso fazer outro exportfs -a e ele exporta a exportação recém-especificada.