Um volume do ZimaOS que fica em modo só de leitura após uma falha de energia deve ser tratado como um evento de proteção do sistema de ficheiros, não como um problema de permissões. Neste caso da versão 1.4.0, o Windows comunicou erros de E/S e o explorador de ficheiros do ZimaOS apresentou “sistema de ficheiros só de leitura”. O utilizador acabou por restaurar o acesso com o fsck.
Essa reparação bem-sucedida é uma evidência útil, mas copiar o comando exato sem identificar primeiro o sistema de ficheiros e o estado de montagem é inseguro. Sistemas de ficheiros diferentes requerem ferramentas de reparação diferentes, e a reparação não deve ser executada cegamente num volume montado.
Como se manifestou a falha
O servidor utilizava uma matriz RAID1 de 2 TB. Após a falha de energia, deixou de ser possível abrir ficheiros de forma fiável através do SMB do Windows, e a criação de uma pasta diretamente no explorador de ficheiros do ZimaOS falhava porque a montagem RAID tinha passado a só de leitura.
Esta combinação é importante: um erro de acesso do lado do cliente, juntamente com uma mensagem de sistema de ficheiros só de leitura no anfitrião, aponta para uma camada abaixo das permissões do Samba. Sugere que o armazenamento ou a integridade do sistema de ficheiros devem ser verificados antes de alterar utilizadores, ACL ou definições de partilhas.
A reparação no fórum foi confirmada pelo utilizador
O utilizador ligou um monitor e um teclado, iniciou sessão com privilégios elevados, identificou o dispositivo do sistema de ficheiros Linux com fdisk -l, executou fsck -f no dispositivo RAID, repetiu a verificação quando ainda havia erros e reiniciou o sistema. Relatou que isso restaurou o funcionamento normal de leitura e escrita.
Este é um resultado real confirmado por um utilizador, mas não foi um procedimento de recuperação elaborado pela IceWhale. A regra mais segura é identificar primeiro o sistema de ficheiros exato. O manual do e2fsck desaconselha a verificação de um sistema de ficheiros ext montado, exceto em casos restritos e definidos de apenas leitura.
Siga uma ordem de recuperação de menor risco
Antes de qualquer reparação, pare as aplicações e as tarefas de sincronização que escrevem no volume. Se ainda for possível ler dados importantes, copie os ficheiros mais valiosos para outro armazenamento saudável. Registe a configuração do conjunto e os erros atuais antes de reiniciar ou alterar a matriz.
A lista de verificação para volumes só de leitura explica este processo para ext4, XFS, Btrfs e ZFS. É um ponto de partida melhor do que assumir que todas as matrizes ZimaOS devem receber o mesmo comando fsck.
Como aceder ao terminal atual do ZimaOS
O ZimaOS atual disponibiliza SSH e um terminal Web integrado através do Modo de programador. A configuração atual do SSH documenta esses métodos de acesso.
Utilize o acesso ao terminal para inspecionar primeiro o dispositivo e o tipo de sistema de ficheiros. Se não for possível desmontar corretamente o volume afetado enquanto o sistema normal está em execução, utilize um ambiente de manutenção ou recuperação adequado em vez de forçar a reparação no local.
Evite que a mesma falha se transforme em perda de dados
Uma UPS pode reduzir os encerramentos abruptos, mas não substitui as cópias de segurança. O artigo sobre os limites da recuperação RAID explica por que razão uma matriz espelhada continua a precisar de uma cópia independente e recuperável.
Conclusão
O caso do fórum foi efetivamente resolvido com uma reparação do sistema de ficheiros, mas a lição não é “execute fsck -f após todas as falhas de energia”. A lição correta é: preserve os dados legíveis, identifique o sistema de ficheiros e o dispositivo, desmonte-o quando necessário, utilize a ferramenta de reparação nativa do sistema de ficheiros e só depois restaure as operações de escrita.
