Executando fsck no disco interno que também possui a pasta criptografada ecryptfs

0

Eu não consegui responder diretamente a isso.

O disco rígido do meu notebook não é criptografado . Dentro da minha pasta pessoal não criptografada, eu tenho uma pasta pessoal que é criptografada usando ecryptfs. Eu segui principalmente este tutorial

Eu sei que se eu tiver a partição LUKS (como eu tenho no meu USB externo), não devo executar o fsck diretamente no disco, ele deve ser executado como

 fsck -M /dev/mapper/luks-4c6...

Mas e a pasta ecryptfs? Desde que é um sistema de arquivos empilhados, eu realmente não tenho controle sobre pular esta pasta ao verificar o disco rígido. Minhas dúvidas são

  • Verificaria a bagunça do disco rígido na (s) pasta (s) ecryptfs
  • Assumindo a resposta como não acima, iria fsck pular esta pasta (mas como o fsck realmente saberia alguma coisa sobre o que está no topo do arquivo? sistema).
  • Por outro lado, como posso garantir que o ecryptfs pastas não são corrompidas. (Algumas vezes eu esqueço de desmontar enquanto desligando o PC).
  • Ou ao contrário de LUKS, eu não preciso me preocupar com fsck ing individual recipientes em ecryptfs. fscking o recipiente subjacente é bom suficiente e suportado.
por Amit 03.10.2015 / 04:18

1 resposta

1

fsck verifica o sistema de arquivos subjacente, físico, em blocos no disco. É necessário Fazer quando ninguém mais está acessando o disco (usuário único, inicialização ao vivo). Naquela época, sua pasta criptografada não é montada, portanto, não é visível, exceto como blocos em disco de dados binários com nomes de arquivos realmente bobos (faça um ls do subdiretório .Private/ para ver o que quero dizer). É somente quando você está logado, e mount ed sua pasta ecryptfs que é descriptografada, e pode-se dizer que "existe". Então, em ordem, as respostas para suas múltiplas perguntas são:

Não.

Não é possível dizer que essa pasta "existe" em fsck time.

Como a pasta criptografada é mount ed e aparece em /etc/mtab , ela será "tratada" quando você fizer um encerramento educado ( sudo shutdown ou shut down do menu Log out ). basta matar a energia, ou parar a VM, você corromperá seus sistemas de arquivos criptografados (e não criptografados), eventualmente, devido a meta informações atualizadas do disco na RAM não serem gravadas em "disco". fsck pode então detectar "consertar") problemas com o sistema de arquivos subjacente, físico, em blocos-em-disco, que poderia destruir o sistema de arquivos criptografado. Fazer shutdowns educados.

Os sistemas de arquivos que você está se preocupando não foram criados em fsck time.

    
por waltinator 03.10.2015 / 06:05