Quando o Docker se recusa a iniciar após uma migração de dados do ZimaOS, a última linha do registo pode ser enganadora. Neste caso de origem, de fevereiro de 2026, o Docker acabou por comunicar que o controlador de armazenamento overlay2 não era suportado. A leitura de algumas linhas anteriores revela a verdadeira falha: o Docker não conseguiu criar ficheiros temporários nem testar o armazenamento overlay porque não havia espaço disponível no dispositivo.
O utilizador tinha um SSD de 180 GB com o ZimaOS e, inadvertidamente, deixara nele uma base de dados do Immich em crescimento. Quando tentou fazer a migração, já não havia espaço livre suficiente para uma transferência limpa. Após várias tentativas e a eliminação manual de registos, os dados das aplicações pareciam ter sido migrados, mas o disco do sistema continuou a atingir 100% e o Docker deixou de conseguir inicializar após o reinício.
O Immich encheu o pequeno SSD do sistema antes da migração
O utilizador instalou o Immich sem mover a respetiva base de dados para fora da unidade do sistema. À medida que a coleção de fotografias cresceu, o disco encheu-se e o ZimaOS começou a comunicar erros.
Isto corresponde às orientações atuais da IceWhale: os dados das aplicações devem ser colocados no espaço de armazenamento principal, e não num pequeno disco do sistema, porque as bibliotecas de fotografias, os metadados multimédia, os índices de documentos, as bases de dados e as caches podem crescer rapidamente.
A própria migração precisava de espaço de trabalho
O utilizador só tentou o fluxo de migração do ZimaOS depois de o disco do sistema já estar criticamente cheio. Afirmou que as primeiras tentativas de migração falharam por não haver espaço livre suficiente para armazenar temporariamente a operação.
Esta é uma importante lição operacional: mova os dados das aplicações antes de o disco do sistema atingir os últimos poucos gigabytes, e não depois de o Docker e os serviços de migração já estarem sem espaço de trabalho.
A mensagem do socket do Docker era apenas um sintoma
As aplicações comunicaram:
Não é possível ligar ao daemon do Docker em unix:///var/run/docker.sock.
O daemon do Docker está em execução?Essa mensagem significa que o daemon do Docker está indisponível. Não identifica por que motivo o daemon falhou.
O Journal revelou a verdadeira causa principal
As linhas importantes eram:
não há espaço disponível no dispositivo
Não foi possível garantir que o perfil predefinido do AppArmor está carregado
mkdir /var/lib/docker/overlay2/check-overlayfs-support...: no space left on device
falhou ao iniciar o daemon: erro ao inicializar o graphdriverO Docker falhou primeiro porque não conseguia escrever dados temporários. Mais tarde, controlador não suportado a mensagem foi uma consequência da falha na inicialização do controlador de armazenamento, não uma prova de que o kernel em execução tivesse subitamente perdido o suporte para overlay2 após a migração.
Por que razão reiniciar o Docker não resolveu o problema
O utilizador tentou reiniciar docker.service e docker.socket manualmente e recebeu a mensagem «Acesso negado». Uma resposta da comunidade associou isso aos controlos de serviço de estilo appliance do ZimaOS.
Mesmo que o reinício do serviço tivesse sido permitido, não teria libertado espaço em disco. O daemon voltaria simplesmente a deparar-se com a mesma falha de escrita.
A eliminação dos ficheiros temporários do Docker não recuperou espaço suficiente
A comunidade sugeriu limpar os ficheiros temporários do Docker depois de verificar primeiro o espaço em disco. O utilizador original tentou fazê-lo e respondeu que a unidade do sistema continuava 100% cheia e que o Docker continuava sem iniciar.
Este resultado negativo é útil: uma pequena limpeza temporária não consegue corrigir um sistema de armazenamento em que o disco do sistema continua completamente saturado.
O utilizador de origem optou pela cópia de segurança e pelo restauro de fábrica
Depois de a tentativa de limpeza falhar, o utilizador decidiu fazer uma cópia de segurança /DATA/AppData e reinstalar/restaurar o ZimaOS. O membro da comunidade recomendou anotar as aplicações instaladas, utilizar o restauro de fábrica do sistema e, em seguida, migrar o armazenamento relacionado com as aplicações para o disco de maior capacidade antes de reinstalar as aplicações.
O tópico público termina depois de o utilizador dizer que faria isso. Não contém uma confirmação após o restauro, pelo que a página não deve apresentar a reinstalação como uma solução final verificada para este utilizador específico.
A migração de dados do ZimaOS atual especifica melhor o que pode ser transferido
A versão atual do ZimaOS disponibiliza categorias de migração separadas para:
- Imagens Docker;
- Dados das aplicações Docker;
- bases de dados dos utilizadores, como Galeria, Transferências, Documentos, Multimédia e Cópia de segurança.
Esta é uma atualização importante do tópico antigo, no qual a discussão por vezes tratava a «migração da AppData» como se abrangesse automaticamente todo o armazenamento do Docker.
Utilize as categorias atuais da Migração de Dados do ZimaOS antes de um disco pequeno do sistema ficar criticamente cheio.
Evite o problema definindo antecipadamente a localização dos dados das aplicações
O ZimaOS atual também disponibiliza uma localização dos dados das aplicações em Definições > Aplicações. A IceWhale recomenda indicar a matriz de armazenamento desde o início, em vez de deixar todo o crescimento persistente das aplicações no dispositivo do sistema.
A explicação atual sobre onde as aplicações do ZimaOS armazenam os dados persistentes é a melhor referência preventiva.
Verifique a capacidade e os inodes
Um sistema de ficheiros pode rejeitar novos ficheiros por não ter blocos livres ou por ter esgotado os inodes. A resolução de problemas na origem sugeria verificar ambos. Neste caso, o registo aponta claramente para um esgotamento normal da capacidade, mas verificar ambos os valores continua a ser um diagnóstico útil e apenas de leitura.
Quando a reinstalação se torna razoável
Se o disco do sistema tiver estado 100% cheio, os metadados de armazenamento do Docker estiverem danificados, o daemon não conseguir iniciar e a limpeza segura não conseguir criar espaço de trabalho suficiente, uma reposição controlada do sistema pode ser mais rápida e segura do que editar manualmente os metadados overlay do Docker.
Proteja primeiro os AppData e os dados do utilizador, compreenda quais os discos que a reposição irá afetar e evite eliminar a única cópia das bases de dados das aplicações.
Perguntas frequentes sobre o Docker após a migração
O overlay2 era realmente incompatível com o hardware de origem?
Os registos mostram primeiro que o Docker não conseguiu criar ficheiros de teste overlay2 porque o disco estava cheio. A mensagem do controlador surgiu após essa falha.
Limpar os ficheiros temporários do Docker resolveu o problema no sistema de origem?
Não. O autor original disse que a unidade do sistema continuava 100% cheia.
A versão atual do ZimaOS permite mover as imagens Docker separadamente dos AppData?
Sim. A Migração de Dados atual apresenta as Imagens Docker e os Dados das Aplicações Docker como categorias móveis separadas.
A reposição de fábrica foi confirmada como bem-sucedida no tópico?
Não. O utilizador disse que avançaria com o procedimento, mas o tópico público termina antes de ser apresentado um resultado após a reposição.
