Selbst als root verweigert das System den Zugriff. Meist ist das Dateisystem schreibgeschützt eingehängt oder die Datei ist unveränderlich.
Aufwand:
ca. 25 Min.
Das Symptom
Ein Befehl scheitert mit Permission denied. Also noch einmal mit sudo. Und wieder:
Permission denied. Als root. Auf einer Datei, deren Rechte völlig normal aussehen. An
diesem Punkt beginnt man an der eigenen Zurechnungsfähigkeit zu zweifeln.
Die „Layer 8“-Wahrheit
Root darf alles – dieser Satz stimmt, aber er stimmt nur innerhalb der Rechteverwaltung.
Es gibt zwei Sperren, die darunter liegen, und die interessieren sich nicht dafür, wer
fragt.
Die erste und häufigste: Das Dateisystem ist schreibgeschützt eingehängt. Wenn der Kernel
beim Zugriff auf einen Datenträger Fehler bemerkt, hängt er ihn zum Schutz der Daten
sofort in den Nur-Lese-Modus um. Ab diesem Moment darf niemand mehr schreiben, auch root
nicht. Das ist keine Schikane, das ist eine Notbremse – und die eigentlich wichtige
Nachricht dahinter lautet: Hier stimmt etwas mit dem Datenträger nicht. Wer nun reflexhaft
wieder beschreibbar einhängt, um endlich weiterarbeiten zu können, überschreibt die
Warnung und schreibt munter auf eine Platte, die gerade stirbt.
Die zweite Sperre ist eleganter und wird fast nie erkannt: das unveränderliche Attribut.
Eine so markierte Datei lässt sich nicht ändern, nicht umbenennen, nicht löschen – und
zwar von niemandem, auch nicht von root. Der Clou ist, dass die gewohnte Anzeige der
Rechte davon nichts verrät. Alles sieht normal aus. Deshalb kann man daran eine
erstaunlich lange Zeit verzweifeln, bis jemand die richtige Frage stellt.
Und diese Frage lautet nicht „warum darf root das nicht“, sondern „was hält ihn davon
ab“.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Prüfen, ob das Dateisystem nur lesbar eingehängt ist
Das ist die häufigste Ursache. Erkennt der Kernel Fehler am Dateisystem, hängt er es sicherheitshalber schreibgeschützt ein. Dann darf auch root nicht schreiben – und das ist Absicht, kein Bug.
mount | grep ' / '
2.
Die Ursache des Schreibschutzes ernst nehmen
Ein schreibgeschützt eingehängtes Wurzeldateisystem ist ein Alarmsignal. Es bedeutet meist, dass der Kernel Fehler gefunden hat. Wer es einfach wieder beschreibbar einhängt, ohne die Ursache zu prüfen, schreibt möglicherweise auf einen sterbenden Datenträger.
3.
Das unveränderliche Attribut prüfen
Eine Datei kann als unveränderlich markiert sein. Dann lässt sie sich selbst von root nicht ändern, umbenennen oder löschen, obwohl die Rechte in der Anzeige völlig normal aussehen. Genau das führt zu ratlosen Blicken.
lsattr datei
4.
Das Attribut entfernen, wenn es berechtigt ist
Ist das unveränderliche Attribut gesetzt und soll die Datei bearbeitet werden, wird es entfernt. Vorher lohnt die Frage, wer es gesetzt hat und warum – oft war es ein Schutz mit gutem Grund.
chattr -i datei
5.
An Sicherheitssysteme denken
SELinux oder AppArmor können einen Zugriff verweigern, obwohl die klassischen Dateirechte ihn erlauben würden. Die Systemprotokolle zeigen solche Verweigerungen. Wer sie ignoriert, sucht den Fehler ewig an der falschen Stelle.
6.
Den Datenträgerzustand prüfen
Bevor ein schreibgeschütztes Dateisystem wieder beschreibbar eingehängt wird, gehören die Systemprotokolle und die SMART-Werte des Datenträgers geprüft. Der Schreibschutz ist häufig das erste sichtbare Symptom einer sterbenden Platte.
Häufige Fragen (FAQ)
?Root darf doch alles. Wieso nicht das?
Root darf alles, was die Rechteverwaltung des Dateisystems betrifft. Er kann aber nicht auf ein Medium schreiben, das schreibgeschützt eingehängt ist, und er umgeht auch nicht das unveränderliche Attribut. Beides sind Sperren unterhalb der Benutzerrechte – sie gelten für jeden.
?Warum ist die Datei überhaupt unveränderlich gesetzt?
Das Attribut wird bewusst gesetzt, um wichtige Konfigurationsdateien vor versehentlichem Überschreiben zu schützen – auch vor Skripten, die als root laufen. Es ist eine Sicherung gegen den eigenen Fehler, nicht gegen Angreifer.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.