Un volume ZimaOS che diventa di sola lettura dopo un'interruzione di corrente deve essere considerato un evento di protezione del filesystem, non un problema di autorizzazioni. In questo caso, con la versione 1.4.0, Windows ha segnalato errori di I/O e il browser dei file di ZimaOS ha restituito «read-only file system». Alla fine, l'utente ha ripristinato l'accesso con fsck.
Questa riparazione riuscita è una prova utile, ma copiare il comando esatto senza prima identificare il filesystem e lo stato di smontaggio non è sicuro. Filesystem diversi richiedono strumenti di riparazione diversi, e la riparazione non deve essere eseguita alla cieca su un volume montato.
Come si è manifestato il problema
Il server utilizzava un array RAID1 da 2 TB. Dopo l'interruzione di corrente, non era più possibile aprire i file in modo affidabile tramite SMB di Windows e la creazione di una cartella direttamente nel browser dei file di ZimaOS non riusciva perché il montaggio RAID era diventato di sola lettura.
Questa combinazione è significativa: un errore di accesso lato client insieme a un messaggio di filesystem di sola lettura lato host indica un problema a un livello inferiore rispetto alle autorizzazioni Samba. Suggerisce di controllare prima l'integrità dello storage o del filesystem, prima di modificare utenti, ACL o impostazioni delle condivisioni.
La riparazione del forum è stata verificata dall'utente
L'utente ha collegato un monitor e una tastiera, ha effettuato l'accesso con privilegi elevati, ha identificato il dispositivo del filesystem Linux con fdisk -l, ha eseguito fsck -f sul dispositivo RAID, ha ripetuto il controllo quando erano rimasti degli errori e ha riavviato il sistema. Ha riferito che questa procedura ha ripristinato il normale comportamento di lettura e scrittura.
Si tratta di un risultato reale verificato dall'utente, ma non di una procedura di ripristino pubblicata da IceWhale. La regola più sicura è identificare prima il filesystem esatto. Il manuale di e2fsck sconsiglia di controllare un filesystem ext montato, salvo casi limitati e ben definiti di sola lettura.
Segui un ordine di ripristino a rischio ridotto
Prima di qualsiasi riparazione, arresta le applicazioni e i processi di sincronizzazione che scrivono sul volume. Se i dati importanti sono ancora leggibili, copia i file più preziosi su uno storage separato e integro. Registra la configurazione del pool e gli errori correnti prima di riavviare il sistema o modificare l'array.
La checklist per i volumi di sola lettura illustra nel dettaglio questo processo per ext4, XFS, Btrfs e ZFS. È un punto di partenza migliore che presumere che ogni array ZimaOS debba ricevere lo stesso comando fsck.
Come accedere al terminale ZimaOS attuale
Le versioni attuali di ZimaOS offrono SSH e un terminale web integrato tramite la Modalità sviluppatore. La configurazione SSH attuale documenta questi metodi di accesso.
Usa l'accesso al terminale per esaminare prima il dispositivo e il tipo di filesystem. Se non è possibile smontare correttamente il volume interessato mentre il sistema normale è in esecuzione, utilizza un ambiente di manutenzione o ripristino appropriato invece di forzare la riparazione sul sistema attivo.
Evita che lo stesso problema si trasformi in una perdita di dati
Un UPS può ridurre gli arresti improvvisi, ma non sostituisce i backup. La distinzione tra RAID e ripristino spiega perché un array con mirroring richiede comunque una copia indipendente e recuperabile.
In sintesi
Il caso del forum è stato effettivamente risolto con una riparazione del filesystem, ma la lezione non è «esegui fsck -f dopo ogni interruzione di corrente». La lezione corretta è: preserva i dati leggibili, identifica il filesystem e il dispositivo, smonta il volume quando necessario, usa lo strumento di riparazione nativo del filesystem e solo dopo ripristina le operazioni di scrittura.
