Quando os Ficheiros do ZimaOS apresentam Erro ao carregar, mas o acesso SMB do Windows continua a funcionar, não assuma imediatamente que o RAID ou os dados desapareceram. Esse foi o padrão observado numa discussão de fevereiro de 2026: a interface de Ficheiros deixou de funcionar após a atualização 1.5.4, enquanto outras aplicações e o acesso a ficheiros através do Samba continuavam funcionais.
Mais tarde, a equipa da IceWhale indicou a causa principal. raller1028 afirmou que, no ZimaOS 1.5.4, quando o disco do sistema está cheio, o serviço Ficheiros pode deixar de funcionar corretamente. A recuperação oficial consistia em libertar espaço no disco do sistema e reiniciar o serviço icewhale-files. Uma solução alternativa da comunidade, que consistia em renomear a base de dados, ajudou vários utilizadores, mas a IceWhale não a apresentou como solução de primeira linha.
Um SMB funcional é uma forte indicação de que os dados e as montagens continuam presentes
O autor original da publicação ainda conseguia aceder aos ficheiros através de uma partilha Samba do Windows. Isso significa que o armazenamento do anfitrião e o caminho dos dados continuavam ativos, embora a aplicação Web Ficheiros não conseguisse apresentá-los.
Esta é uma distinção importante entre:
- perda de armazenamento/dados;
- falha do serviço Ficheiros;
- falha do navegador/interface.
Os Ficheiros não são um contentor Docker normal da App Store
Por isso, é esperado que docker ps não apresente um contentor dos Ficheiros. Reiniciar contentores Docker aleatórios não irá reparar o serviço nativo Ficheiros.
A IceWhale identificou o armazenamento cheio do sistema como a causa do problema na versão 1.5.4
A 26 de fevereiro, raller1028, da IceWhale, escreveu que o problema “deveria” ser causado pelo disco do sistema estar cheio na versão 1.5.4.
A sequência oficial de recuperação era:
- libertar algum espaço no disco do sistema através da linha de comandos;
- reiniciar o serviço Ficheiros:
systemctl restart icewhale-filesAos utilizadores que não estivessem familiarizados com a limpeza através da linha de comandos foi recomendado contactar o suporte, em vez de eliminarem ficheiros indiscriminadamente.
Porque é que um disco do sistema cheio pode fazer falhar os Ficheiros enquanto o SMB continua a funcionar
Os serviços nativos precisam de espaço disponível para bases de dados, estado, ficheiros temporários, registos ou operações do serviço. Os dados grandes dos utilizadores podem permanecer intactos noutra matriz de armazenamento, enquanto uma pequena partição do sistema chega aos 100% de utilização e provoca uma falha específica do serviço.
Por isso, verificar apenas se “o meu RAID tem espaço livre” não é suficiente.
Mantenha os dados crescentes das aplicações fora do disco do sistema
A documentação atual do ZimaOS recomenda mover os dados das aplicações para um espaço de armazenamento real, em vez de permitir que as bases de dados Docker, as miniaturas e as caches encham o disco do sistema.
Utilize as orientações atuais do ZimaOS relativas ao armazenamento das aplicações para evitar outra fonte de pressão sobre o disco do sistema.
A renomeação de files.db pela comunidade funcionou para vários utilizadores
Mais tarde, um utilizador da comunidade publicou:
mv /var/lib/casaos_data/.casaos/files.db /var/lib/casaos_data/.casaos/files.db.bak
systemctl restart icewhale-filesVários participantes responderam que esta operação restaurou os Ficheiros.
Ainda assim, isto deve ser considerado um método de recuperação secundário da comunidade. A equipa da IceWhale perguntou imediatamente qual era a importância de remover a base de dados dos Ficheiros e não substituiu as orientações oficiais — “libertar espaço no sistema e reiniciar o serviço” — por este comando.
Renomear uma base de dados é mais seguro do que eliminá-la, mas continua a alterar o estado da aplicação
O comando da comunidade mantém uma cópia .bak em vez de apagar a base de dados. Isso é melhor para uma reversão, mas a reconstrução da base de dados dos Ficheiros pode alterar os metadados indexados ou outro estado do serviço.
Não utilize este método como primeira ação quando o disco do sistema está simplesmente cheio.
Não assuma que o erro da versão 1.5.4 persiste no ZimaOS atual
O ZimaOS atual encontra-se na versão 1.7.x e continua a receber correções para os Ficheiros, o armazenamento, a memória, a segurança e o armazenamento das aplicações. O problema histórico é útil porque ensina a distinguir uma falha do serviço de uma perda de dados, não porque todos os erros modernos dos Ficheiros tenham a mesma causa.
Se o problema voltar a ocorrer atualmente, registe primeiro o espaço livre atual do sistema, a versão atual, o estado do serviço e se o SMB ou outro método de acesso aos ficheiros continua a funcionar.
Liberte espaço de forma deliberada
Não execute scripts gerais de limpeza em diretórios do sistema desconhecidos. Identifique caches grandes de aplicações, dados Docker, cópias de segurança ou registos e, sempre que possível, utilize os controlos atuais de limpeza/migração do ZimaOS.
Perguntas frequentes sobre o erro de carregamento dos Ficheiros
O SMB continuava a funcionar no caso original?
Sim, o que indicava fortemente que os dados e as montagens continuavam presentes.
O que identificou a equipa da IceWhale como o problema da versão 1.5.4?
Um disco do sistema cheio, que fazia com que o serviço Ficheiros deixasse de funcionar corretamente.
Qual era o comando oficial para reiniciar o serviço?
systemctl restart icewhale-files.
A renomeação de files.db era a orientação oficial de primeira linha?
Não. Era uma solução alternativa da comunidade, confirmada por vários utilizadores, enquanto a orientação de primeira linha da IceWhale era libertar espaço e reiniciar o serviço Ficheiros.
