Como corrigir uma montagem vinculada do Docker que, de repente, fica só de leitura
Um bind mount do Docker torna-se só de leitura quando o Docker recebe um caminho só de leitura ou quando o sistema de ficheiros do anfitrião deixa de aceitar escritas.
Como um bind mount expõe diretamente um caminho do anfitrião dentro do contentor, o contentor não consegue reparar sozinho um disco, sistema de ficheiros, sinalizador de montagem ou política de segurança subjacente. A recuperação mais segura consiste em parar as escritas, comparar a montagem do contentor com a montagem do anfitrião, determinar se o comportamento só de leitura foi configurado ou desencadeado por um erro e restaurar o estado saudável do armazenamento antes de reiniciar a aplicação.
Confirme Qual o Caminho que Está Só de Leitura
Teste uma escrita inofensiva dentro do contentor, no destino do bind, e outra escrita no anfitrião, no caminho de origem. Registe o erro exato em vez de presumir que todas as falhas de permissões significam que o sistema de ficheiros está só de leitura.
Um caso no fórum do Docker mostra que um bind principal só de leitura pode impedir o Docker de criar um ponto de montagem aninhado, porque o diretório necessário não pode ser criado no sistema de ficheiros principal só de leitura.
Se o anfitrião conseguir escrever mas o contentor não, inspecione as opções de montagem do Docker e os controlos de segurança. Se ambos falharem com um erro de sistema de ficheiros só de leitura, pare de alterar os utilizadores do contentor e transfira o diagnóstico para a montagem do anfitrião e o dispositivo de armazenamento.
Verifique os Sinalizadores de Montagem Efetivos do Docker
Inspecione a configuração do contentor em execução, em vez de consultar apenas o ficheiro Compose atual. Confirme a origem, o destino, o modo de propagação e se a montagem está marcada como só de leitura através de :ro, da sintaxe longa, de um ficheiro de substituição ou de uma ferramenta de implementação.
Um problema no cliente Docker documenta casos em que os caminhos montados pareciam só de leitura porque a configuração em execução diferia da configuração pretendida com acesso de leitura e escrita. A evidência importante é o modo de montagem efetivo associado ao contentor em execução.
Se a montagem for intencionalmente só de leitura, remova esse sinalizador apenas quando a aplicação precisar realmente de escrever. Recrie o contentor depois de alterar a declaração, porque editar um ficheiro Compose não altera retroativamente uma montagem existente.
Determine se o Anfitrião Remontou o Sistema de Ficheiros como Só de Leitura
Verifique a tabela de montagens do anfitrião, o registo do kernel, o registo do armazenamento e o estado do sistema de ficheiros em busca de erros de E/S, falhas do journal, erros de soma de verificação, reinicializações do dispositivo ou uma remontagem de proteção. Não force uma remontagem com leitura e escrita antes de compreender por que razão a proteção foi ativada.
Um caso de suporte do Unraid descreve uma falha do appdata do Docker depois de um sistema de ficheiros ter ficado só de leitura, incluindo erros ao criar diretórios do Plex. Esse padrão aponta para uma falha do sistema de ficheiros do anfitrião, e não para uma definição de permissões do contentor.
Pare os contentores afetados e preserve os diagnósticos. Repare o disco, o conjunto, o cabo, o sistema de ficheiros ou o journal através do fluxo de manutenção suportado pela plataforma e, em seguida, confirme que o caminho do anfitrião está saudável antes de permitir novamente que os contentores de bases de dados ou multimédia escrevam.
Inspecione as Montagens Aninhadas e Sobrepostas
Apresente todas as montagens bind e os volumes nomeados cujo destino se encontre dentro de outro diretório montado. As montagens sobrepostas podem ocultar diretórios, herdar comportamentos de acesso inesperados ou exigir que o Docker crie um ponto de montagem sob um diretório principal só de leitura.
Uma discussão no Server Fault explica que sobrepor uma montagem com leitura e escrita e uma montagem mais abrangente só de leitura em caminhos relacionados do contentor pode produzir resultados confusos. Como esse domínio já é utilizado noutro ponto deste lote, a regra prática é mapear toda a árvore de destinos antes de alterar as permissões.
Crie os diretórios necessários no anfitrião antes de iniciar o contentor, evite montar um elemento subordinado com capacidade de escrita sob um diretório principal só de leitura quando o ambiente de execução tiver de o criar e mantenha os caminhos persistentes explícitos no Compose. Recrie o contentor depois de simplificar a árvore de montagens.
Separe o Estado Só de Leitura das Permissões e da Política de Segurança
Compare o erro do teste de escrita com o proprietário, o modo, a ACL, a etiqueta SELinux, o perfil AppArmor e o ID de utilizador do contentor do diretório de origem. “Permissão negada” e “sistema de ficheiros só de leitura” são falhas diferentes e exigem reparações diferentes.
Um guia de resolução de problemas de armazenamento agrupa os incidentes de volumes só de leitura em sinalizadores de montagem, erros do sistema de ficheiros, contextos de segurança e problemas do controlador de armazenamento. Essa classificação ajuda a evitar uma resposta automática de chmod 777 a um estado só de leitura na camada de armazenamento.
Se as permissões estiverem incorretas, corrija a propriedade ou as ACL no anfitrião utilizando o UID e o GID pretendidos pelo contentor. Se o próprio sistema de ficheiros estiver só de leitura, as alterações de permissões irão falhar e não devem ser utilizadas como substituto da reparação do sistema de ficheiros.
Reinicie a Aplicação Apenas Depois de um Teste de Escrita no Anfitrião Ser Bem-Sucedido
Escreva, sincronize, leia e elimine um ficheiro temporário no caminho do anfitrião e, em seguida, repita o teste através de um contentor temporário com a mesma declaração de montagem e o mesmo utilizador. Confirme que o sistema de ficheiros esperado continua montado depois de um reinício.
O guia da ZimaSpace sobre encontrar uma dependência de contentor que provoca um ciclo de reinício é a verificação seguinte se a aplicação continuar a reiniciar em ciclo depois de o armazenamento voltar a permitir escritas.
A reparação só está concluída quando o sistema de ficheiros do anfitrião estiver saudável, a montagem efetiva do Docker tiver leitura e escrita por conceção, a aplicação conseguir atualizar os seus ficheiros persistentes e não surgirem novos erros de E/S ou do sistema de ficheiros durante uma utilização prolongada.
Produtos recomendados
Suporte e Dicas
Mais para Ler
Guia de armazenamento para gravação de TV em direto: capacidade, retenção e limpeza
Meça gravações reais, reserve margem de segurança, combine limites de idade e capacidade e confirme que o programa elegível mais antigo é removido antes...
Fluxo de recuperação de metadados de multimédia doméstica após o restauro de uma base de dados
Proteja o estado restaurado, verifique a identidade e os caminhos dos ficheiros multimédia e, em seguida, corrija as capas ou correspondências em falta numa...
Lista de verificação de compatibilidade do cliente Jellyfin para áudio, vídeo e legendas
Teste ficheiros representativos, uma variável de cada vez, e registe Direct Play, remux, conversão de áudio, transcodificação de vídeo ou falha para cada cliente.
