ext4 aktiviert Notfall-Schreibschutz · Linux Fix Lab

Symptome und Geltungsbereich

Anwendungen erhalten beim Speichern plötzlich Read-only file system.
ext4 meldet Dateisystemfehler oder einen Übergang zum Schreibschutz.

Betroffene Umgebung

ext4-Dateisysteme mit errors=remount-ro oder erzwungener Journal-Fehlerbehandlung; Verhalten hängt vom Kernel ab.

Erkennbare Meldungen (synthetische Beispiele)

EXT4-fs error (device sda2): ext4_lookup:1850: inode #41: comm app: deleted inode referenced: 52

Den ersten Fehler untersuchen und Daten sichern; eine Zeile unterscheidet Software-, RAM- und Speicherursachen nicht.

EXT4-fs (sda2): Remounting filesystem read-only

Spätere Schreibfehler sind eine erwartbare Folge. Sichtbare Mount-Flags können bei entsprechenden Kerneln vom internen Notfallzustand abweichen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Inkonsistente Metadaten oder fehlgeschlagenes Journal-I/O können Schutz auslösen; vorherige Blockgerätefehler können die zugrunde liegende Ursache zeigen.
Ein absichtlich nur lesbar eingebundenes Dateisystem ist ein anderer Konfigurationsfall, solange keine ext4-Fehlerbehandlung protokolliert ist.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Kernel-Log dieses Starts bei Bedarf mit Journalrechten lesen. Den ersten ext4- und Block-I/O-Fehler suchen.

journalctl -k -b --no-pager -n 400

Ergebnis einordnen: Der erste Metadaten- oder Journalfehler ist hilfreicher als spätere EROFS-Meldungen. Wiederholte SATA/NVMe-Fehler erfordern zuerst eine Reparatur des Speicherpfads.

Prüfschritt 2

/affected/path durch einen vorhandenen Pfad auf dem betroffenen Dateisystem ersetzen. Mount-Informationen lesen, ohne sie zu verändern.

findmnt -T /affected/path -o TARGET,SOURCE,FSTYPE,OPTIONS

Ergebnis einordnen: ext4 und Quellgerät bestätigen. Manche Kernel behalten intern Notfall-Schreibschutz bei, obwohl rw sichtbar bleibt; deshalb das Journal zusätzlich zu den Flags auswerten.

Nächste Schritte nach Befund

Schreibzugriffe beenden und Quellgerät prüfen

Wenn ext4 den Schutz aktiviert hat, betroffene Anwendungen beenden und lesbare Daten auf ein anderes Gerät sichern. Wiederkehrende Laufwerks-, Strom- oder Übertragungsfehler vor jeder Metadatenreparatur beheben.

Vorsicht: Den Schutz nicht durch errors=continue oder wiederholtes remount-rw umgehen. Ein normales ro-Mount kann das Journal wiedergeben; Rettungskopien benötigen eine bewusste Vorgehensweise.

Wiederherstellung / Rücknahme: Dienste erst nach geklärter Gerätestabilität und Dateisystemkonsistenz wieder starten. Beschädigte Dateien aus einem verlässlichen Backup wiederherstellen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Offline-Prüfung von ext4 planen

Wenn Daten gesichert und der Speicherpfad stabil sind, mit einem Rettungsmedium das betroffene Dateisystem aushängen und vor Reparaturen eine e2fsck-Prüfung ohne Änderungen auswerten. Root-Dateisysteme brauchen eine getrennte Startumgebung.

Vorsicht: Ein eingebundenes Dateisystem niemals reparieren. Geräte- oder Mapper-Pfad bestätigen; bei unersetzlichen Daten zuerst auf einem Abbild arbeiten.

Wiederherstellung / Rücknahme: Dateisystemreparaturen sind nicht zuverlässig rückgängig zu machen; Abbild oder Backup behalten und daraus wiederherstellen, wenn das Ergebnis unbrauchbar ist.