Ein ZimaOS-Volume, das nach einem Stromausfall schreibgeschützt wird, sollte als Dateisystem-Schutzereignis und nicht als Berechtigungsproblem behandelt werden. In diesem Fall mit Version 1.4.0 meldete Windows I/O-Fehler, und der ZimaOS-Dateibrowser zeigte „read-only file system“ an. Der Benutzer konnte den Zugriff letztlich mit fsck wiederherstellen.
Diese erfolgreiche Reparatur ist ein nützlicher Hinweis. Den exakten Befehl jedoch zu kopieren, ohne zuvor das Dateisystem und den Einbindungsstatus zu ermitteln, ist unsicher. Verschiedene Dateisysteme erfordern unterschiedliche Reparaturwerkzeuge, und eine Reparatur sollte nicht blind auf ein eingebundenes Volume angewendet werden.
So zeigte sich der Fehler
Der Server verwendete ein 2-TB-RAID1-Array. Nach dem Stromausfall konnten Dateien über Windows-SMB nicht mehr zuverlässig geöffnet werden, und das Erstellen eines Ordners direkt im ZimaOS-Dateibrowser schlug fehl, weil der RAID-Einhängepunkt schreibgeschützt war.
Diese Kombination ist relevant: Ein clientseitiger Zugriffsfehler zusammen mit einer hostseitigen Meldung über ein schreibgeschütztes Dateisystem deutet auf ein Problem unterhalb der Samba-Berechtigungen hin. Daher sollte die Integrität des Speichers oder Dateisystems überprüft werden, bevor Benutzer, ACLs oder Freigabeeinstellungen geändert werden.
Die Reparatur im Forum wurde vom Benutzer verifiziert
Der Benutzer schloss einen Monitor und eine Tastatur an, meldete sich mit erweiterten Berechtigungen an, ermittelte das Linux-Dateisystemgerät mit fdisk -l, führte fsck -f für das RAID-Gerät aus, wiederholte die Prüfung, als weiterhin Fehler gefunden wurden, und startete das System neu. Nach eigenen Angaben wurde dadurch das normale Lese-/Schreibverhalten wiederhergestellt.
Das ist ein tatsächlich vom Benutzer verifiziertes Ergebnis, aber keine von IceWhale verfasste Wiederherstellungsanleitung. Die sicherere Vorgehensweise besteht darin, zuerst das genaue Dateisystem zu ermitteln. Das e2fsck-Handbuch warnt davor, ein eingebundenes ext-Dateisystem zu prüfen, außer in eng begrenzten Fällen im Nur-Lese-Modus.
Verwenden Sie eine Wiederherstellungsreihenfolge mit geringerem Risiko
Beenden Sie vor jeder Reparatur Apps und Synchronisierungsaufträge, die auf das Volume schreiben. Wenn wichtige Daten noch lesbar sind, kopieren Sie die wertvollsten Dateien auf einen separaten, intakten Speicher. Dokumentieren Sie das Pool-Layout und die aktuellen Fehler, bevor Sie das System neu starten oder das Array ändern.
Die Checkliste für schreibgeschützte Volumes beschreibt diesen Prozess für ext4, XFS, Btrfs und ZFS ausführlicher. Sie ist ein besserer Ausgangspunkt, als anzunehmen, dass auf jedes ZimaOS-Array derselbe fsck-Befehl angewendet werden sollte.
So greifen Sie auf das aktuelle ZimaOS-Terminal zu
Das aktuelle ZimaOS bietet SSH und über den Entwicklermodus ein integriertes Webterminal. Die aktuelle SSH-Einrichtung beschreibt diese Zugriffsmethoden.
Verwenden Sie den Terminalzugriff, um zunächst das Gerät und den Dateisystemtyp zu überprüfen. Wenn das betroffene Volume während des laufenden normalen Systems nicht sauber ausgehängt werden kann, verwenden Sie eine geeignete Wartungs- oder Wiederherstellungsumgebung, statt eine Reparatur direkt im laufenden Betrieb zu erzwingen.
Verhindern Sie, dass derselbe Fehler zu Datenverlust führt
Eine USV kann abrupte Abschaltungen reduzieren, ersetzt jedoch keine Backups. Die Grenzen der RAID-Wiederherstellung erklären, warum ein gespiegeltes Array weiterhin eine unabhängige, wiederherstellbare Kopie benötigt.
Fazit
Der Fall aus dem Forum wurde tatsächlich durch eine Dateisystemreparatur gelöst. Die Lehre daraus lautet jedoch nicht: „Führe nach jedem Stromausfall fsck -f aus.“ Die richtige Vorgehensweise ist: lesbare Daten sichern, Dateisystem und Gerät ermitteln, das Volume bei Bedarf aushängen, das native Reparaturwerkzeug des Dateisystems verwenden und erst danach Schreibvorgänge wieder zulassen.
