A partição do Ubuntu 16.04 desmontada ao remover uma grande quantidade de arquivos

Question

Eu tenho um dual boot Ubuntu 16.04 / MacOS El Capitan e uma partição compartilhada no formato padrão do Mac (HFS +). Minha dupla inicialização e compartilhamento de partição estão funcionando bem e eu posso acessá-lo de ambos os lados.

Quando estou no Ubuntu e trabalhando nesta partição compartilhada (HFS +), arquivos na lixeira são transferidos para a pasta de lixo do Ubuntu e o sistema é perdido:

• Eu posso ver arquivos na pasta da lixeira, mas não posso excluir nem restaurá-los.
• Quando eu apago enormes quantidades de dados (estou trabalhando com milhares de imagens), a partição é automaticamente desmontada do meu sistema Ubuntu durante o processo de exclusão. Para acessá-lo, eu preciso fazer uma montagem manual após a reinicialização ou mudar para o MacOS e voltar.

Eu tentei:

• excluindo arquivos da linha de comando
• Esvazie / restaure a lixeira da exibição
• Mate o processo de lixeira nos processos em execução

Alguém tem uma ideia do que está causando o problema e o que eu posso fazer para corrigi-lo?

    

Answer 1

Primeiro, o HFS + é um sistema de arquivos não nativo do ponto de vista do Linux, portanto, é esperada alguma estranheza com ele. Dito isso, desmontar completamente o sistema de arquivos ao excluir arquivos vai além do tipo de peculiaridades que eu esperaria, mas pode ser que isso seja pelo menos parte do que está acontecendo. Se sim, e se nenhuma das sugestões abaixo ajudar, mudar para FAT pode fazer o truque. Embora o FAT também seja não-nativo, seus drivers (tanto no Linux quanto no macOS) estão maduros o suficiente para não causar tais problemas. OTOH, FAT também é muito limitado comparado ao HFS +, então pode não ser adequado (como se você precisasse armazenar arquivos grandes).

De qualquer forma, alguns problemas específicos podem estar em ação aqui:

• Registro no diário - Por padrão, o macOS cria volumes HFS + com o registro no diário ativo. Na verdade, esse padrão não pode ser desabilitado em versões recentes do macOS ao usar o Utilitário de Disco GUI. O registro no diário, no entanto, é mal suportado nos drivers HFS + do Linux. Assim, para uma partição de dados compartilhada, é melhor desabilitar o registro no diário. Infelizmente, não sei como fazer isso em um volume existente; mas talvez uma pesquisa na Web mude alguma coisa. Se não, ou se você não se importa em fazer um malabarismo de backup-reformat-restore, você pode fazer isso. Quando você fizer isso, sugiro usar mkfs.hfsplus no Linux para criar o novo sistema de arquivos. Para criar um sistema de arquivos sem journaling, você a opção -J . (Digite man mkfs.hfsplus para saber mais sobre esse comando.) Se o comando não estiver instalado, talvez seja necessário instalar o pacote hfsprogs . Há uma maneira de fazer isso no macOS também; Eu acredito que o comando é newfs ou algo similar. Não me lembro dos detalhes, no entanto.
• IDs de usuário coordenados - Por padrão, a primeira ID de usuário (UID) do Ubuntu é 1000, enquanto é 501 no macOS. Assim, quando você tenta compartilhar arquivos em uma partição HFS + nesses sistemas operacionais, os arquivos parecerão pertencer a diferentes usuários em cada sistema operacional. Embora seja possível definir permissões livremente ou fazer uso pesado de sudo para permitir que o compartilhamento de arquivos funcione, uma solução melhor é coordenar os valores de UID nas duas instalações. Minha resposta para esta pergunta on AskUbuntu descreve como fazer isso no Ubuntu, e fornece ponteiros para outros sites que descrevem como fazê-lo no macOS. (Fazer a mudança no macOS é preferível, mas o processo é mais entediante no macOS.) Ao sugerir essa mudança, minha hipótese é que você pode estar correndo em problemas de permissões e que esses problemas estão interagindo com bugs do sistema de arquivos que estão causando o sistema de arquivos para ser desmontado.
• Erros do sistema de arquivos - Se o sistema de arquivos foi danificado, pode estar fazendo com que o kernel o desmonte repentinamente. Você pode executar fsck em uma partição HFS + no Linux, e isso deve corrigir o problema, desde que o pacote hfsprogs esteja instalado. A Apple fez open-source de seu código HFS +, portanto, em teoria, isso deve ser praticamente idêntico a executar uma verificação no macOS; no entanto, a Apple vem fazendo algumas alterações em seus sistemas de arquivos ultimamente, e não sei se essas mudanças funcionaram nos pacotes das distribuições Linux, então pode ser mais seguro fazer o trabalho a partir do macOS, usando o Utilitário de Disco. Se o Utilitário de Disco lhe der uma opção para fazê-lo, não ative um diário na partição, pelas razões anotadas anteriormente.

Você pode obter algumas pistas sobre o que está causando o problema, observando o buffer de anel do kernel imediatamente após o problema ocorrer. Você pode fazer isso digitando dmesg para ver a coisa toda ou dmesg | tail para ver as últimas linhas. (Você pode estender o número de linhas mostradas através da opção -n para tail , como em dmesg | tail -n 20 ; ou você pode usar less em vez de tail para poder percorrer a coisa toda.) buffer de anel do kernel deve registrar informações sobre falhas do kernel, o que é uma desmontagem não solicitada de um sistema de arquivos. OTOH, é concebível que o que quer que esteja causando a desmontagem não seja realmente uma falha do kernel, ou o relatório de erro não acontece por algum motivo. Se você tentar as sugestões acima e elas não ajudarem, mas se o buffer de anel do kernel mostrar algo suspeito, você pode tentar postar os detalhes.