nano speichert nicht: Berechtigung verweigert

Warum nano Ihre Datei nicht speichert

nano speichert Ihre Datei aus einem von vier Gründen nicht: Sie sind nicht Eigentümer der Datei, das übergeordnete Verzeichnis erlaubt die von nano benötigte Aktion nicht, das Dateisystem ist schreibgeschützt oder voll, oder Sie befinden sich in einem Container, der unter einer anderen Benutzer-ID läuft. Die ersten beiden Ursachen sind Berechtigungsprobleme, die letzten beiden nicht. Prüfen Sie die Ursachen in dieser Reihenfolge. Der erste Grund tritt in den meisten Fällen auf, lässt sich mit einem Befehl bestätigen, und die Lösung ist sudoedit statt sudo nano.

Solange der Editor noch geöffnet ist, geht nichts verloren. Ihr Text befindet sich im Arbeitsspeicher. Sie können die Datei geöffnet lassen, den Puffer in einen Pfad schreiben, für den Sie Schreibrechte haben, und die Datei anschließend an die richtige Stelle verschieben. Diese Ausweichlösung wird gegen Ende dieser Anleitung beschrieben.

Führen Sie diese Prüfungen aus, bevor Sie Berechtigungen ändern

Richten Sie jeden Befehl auf den tatsächlichen Pfad, den Sie bearbeiten. Die Befehle beantworten unterschiedliche Fragen. Führen Sie sie daher alle aus, bevor Sie etwas ändern. Wenn Sie Berechtigungen ändern, bevor Sie wissen, welche Prüfung fehlschlägt, entsteht meist zusätzlich zum ersten Problem ein zweites.

id
ls -l /etc/nginx/nginx.conf
ls -ld /etc/nginx
namei -l /etc/nginx/nginx.conf
findmnt -no SOURCE,FSTYPE,OPTIONS -T /etc/nginx/nginx.conf
df -h /etc/nginx
df -i /etc/nginx

id gibt die Benutzer-ID und die Gruppen-IDs aus, die aktuell für Sie gelten. ls -l zeigt den Eigentümer, die Gruppe und die Berechtigungsbits der Datei selbst. ls -ld zeigt dasselbe für das Verzeichnis, in dem sich die Datei befindet. Das ist eine separate Frage mit einer separaten Antwort. namei -l durchläuft jeden Bestandteil des Pfads und listet Eigentümer und Berechtigungen für jeden Bestandteil auf. Damit beantwortet die Ausgabe beide Fragen gleichzeitig. findmnt nennt das Dateisystem unter diesem Pfad und die Mount-Optionen, mit denen es eingebunden wurde. df -h gibt den freien Speicherplatz aus. df -i gibt die freien Inodes aus. Diese können unabhängig vom Speicherplatz ausgehen. Wenn Ihnen diese Berechtigungszeichenfolgen noch nicht vertraut sind, beginnen Sie mit dem Lesen der Berechtigungszeichenfolge, die ls -l ausgibt.

Ursache 1: Die Datei gehört root, Ihnen jedoch nicht

Lesen und Schreiben sind separate Berechtigungen. Die meisten Dateien unter /etc sind für alle Benutzer lesbar. Deshalb öffnet nano die Datei, zeigt den Inhalt an und lässt Sie uneingeschränkt Text eingeben: Nichts davon schreibt auf die Festplatte. Die Ablehnung erfolgt beim Speichern. Dann vergleicht der Kernel Ihre Benutzer-ID und Ihre Gruppen-IDs mit den Bits für Eigentümer, Gruppe und andere Benutzer der Datei. nano gibt lediglich die Meldung des Kernels weiter. Keine nano-Option ändert daran etwas.

id und ls -l klären die Situation eindeutig. Die Datei gehört root, Sie sind nicht root, und die Berechtigungsbits für andere Benutzer erlauben kein Schreiben. Erneutes Drücken von Ctrl-O hilft nicht.

Warum sudoedit die richtige Methode zum Bearbeiten einer root-eigenen Datei ist

SUDO_EDITOR=nano sudoedit /etc/nginx/nginx.conf

sudo erstellt eine temporäre Kopie der Datei, setzt Sie als Eigentümer ein, startet nano für diese Kopie unter Ihrem eigenen Benutzerkonto und kopiert das Ergebnis nach dem Beenden des Editors mit root-Berechtigungen zurück an den ursprünglichen Speicherort. Der Editor läuft nie als root. sudo -e ist derselbe Befehl unter einem anderen Namen. Der Editor wird zuerst aus SUDO_EDITOR, dann aus VISUAL und anschließend aus EDITOR ausgewählt. Wenn Sie daher export EDITOR=nano in Ihrem Shell-Profil setzen, ist dieser Editor überall die Standardeinstellung. Wenn in Ihrer sudoers-Konfiguration das Flag env_editor deaktiviert ist, werden diese Variablen ignoriert. Der Editor wird dann stattdessen aus der Einstellung editor in sudoers übernommen.

sudo nano speichert die Datei ebenfalls. Genau darin liegt das Problem. Der vollständige interaktive Editor erhält für die gesamte Dauer der Sitzung root-Berechtigungen für das gesamte Dateisystem. Ein falsch eingegebener Pfad an der Speicheraufforderung kann daher Ihren Text als root über eine andere Systemdatei schreiben. Mit einem normalen Benutzerkonto zu arbeiten und sudo nur für die erforderlichen Schritte aufzurufen, ist eine sinnvolle Gewohnheit. sudoedit zeigt diese Vorgehensweise beim Bearbeiten einer Konfigurationsdatei unmittelbar in der Praxis.

Zwei sudoedit-Regeln überraschen viele Benutzer. sudoedit verweigert die Bearbeitung eines symbolischen Links. Außerdem verweigert sudoedit die Bearbeitung einer Datei in einem Verzeichnis, in das Sie schreiben können, sofern Sie nicht root sind. Die zweite Regel ist erforderlich, weil jeder Benutzer mit Schreibrechten für das Verzeichnis die Datei austauschen kann, während sie im Editor geöffnet ist. Beide Verhaltensweisen entsprechen den sudoers-Standardeinstellungen (sudoedit_follow deaktiviert, sudoedit_checkdir aktiviert). Eine Datei, die noch nicht existiert, wird für Sie erstellt.

Ursache 2: Was das übergeordnete Verzeichnis tatsächlich steuert

Hinweise für andere Editoren besagen, dass zum Speichern Schreibberechtigungen für das Verzeichnis erforderlich sind, weil viele Editoren eine neue Datei schreiben und sie über die alte Datei umbenennen. nano arbeitet nicht auf diese Weise. Es öffnet die angegebene Datei und schreibt in diese Datei. Bei einer bereits vorhandenen Datei wird das Schreibbit des Verzeichnisses daher nie geprüft.

Das Verzeichnis steuert weiterhin andere Vorgänge. Deshalb steht ls -ld auf der Prüfliste:

• Zum Erstellen einer noch nicht vorhandenen Datei benötigen Sie Schreib- und Ausführungsberechtigungen für das Verzeichnis, weil ein neuer Name hinzugefügt werden muss. Ihre umask legt die Startberechtigungen dieser neuen Datei fest.
• Um die Datei überhaupt zu erreichen, benötigen Sie Ausführungsberechtigungen, auch Suchberechtigungen genannt, für jedes Verzeichnis im Pfad. Fehlt sie in einem Verzeichnis, wird der gesamte darunterliegende Inhalt blockiert. namei -l zeigt Ihnen, in welchem Verzeichnis sie fehlt.
• Beim Speichern mit aktivierten Sicherungskopien oder aktivierter Dateisperre wird eine zweite Datei neben dem Original geschrieben. Diese Funktionen benötigen daher ein beschreibbares Verzeichnis. Sicherungskopien werden mit der Option -B oder mit set backup in einer nanorc aktiviert. Die Dateisperre wird mit -G oder set locking aktiviert. Beide Funktionen sind deaktiviert, sofern Sie oder Ihre Distribution sie nicht aktiviert haben.

Verzeichnisberechtigungen sind auch an anderen Stellen im System entscheidend. Der SSH-Server weist einen Schlüssel zurück, wenn Ihr Home-Verzeichnis oder Ihr .ssh-Verzeichnis von anderen Benutzern beschrieben werden kann. Das ist eine häufige Ursache dafür, dass SSH Ihren Schlüssel bei der Anmeldung zurückweist.

Weil nano in die bereits vorhandene Datei schreibt, behält die Datei ihren Inode. Dieser ist die Identität der Datei auf dem Datenträger, die hinter dem Namen steht. Jeder Prozess, der die Datei geöffnet hält, verfolgt sie weiterhin, und ein einzelnes Datei-Bind-Mount in einen Container funktioniert weiter. Editoren, die beim Speichern die Datei ersetzen, unterbrechen dieses Mount, weil das Mount dem Inode und nicht dem Namen folgt.

Cause 3: the filesystem is read only, or it has nothing left

findmnt reporting ro in the options means the write was never going to succeed. Either the filesystem was mounted that way, through /etc/fstab or a read only bind mount, or the kernel remounted it read only after a disk error. The second case is the serious one. sudo dmesg -T | tail -50 shows the input/output and filesystem errors that led to the remount, and the repair is a filesystem check while it is unmounted, which on a VPS means booting the provider's rescue console.

A full filesystem fails the same write for a different reason. df -h covers the ordinary case. df -i covers the case people miss: inodes come from a fixed pool created when the filesystem was made, and a tree of tiny files can use them all while df -h still shows free gigabytes. When space is gone and nothing obvious is holding it, df and du disagreeing about a full disk covers the deleted-but-still-open file that causes it.

One detail explains a confusing symptom here. ext4 reserves a share of its blocks for root when the filesystem is created, so root keeps writing after ordinary users are refused. sudo then looks like the fix, the disk fills the rest of the way, and the problem returns in a worse form.

Because nano truncates the file before writing the new contents, a write that runs out of space partway can leave the file shorter than it was. Copy a config you care about before editing it on a filesystem that is nearly full. sudo cp -a /etc/nginx/nginx.conf /root/nginx.conf.bak keeps the owner, group and permissions on the copy.

Ursache 4: Sie bearbeiten in einem Container einen Bind-Mount

Dateibesitz wird numerisch gespeichert. Der Kernel speichert eine Benutzer-ID. Der angezeigte Name stammt von dem /etc/passwd, das die Zuordnung vornimmt. Deshalb kann dieselbe Datei auf dem Host unter einem Namen und im Container unter einem anderen Namen oder nur als Zahl angezeigt werden. Vergleichen Sie die IDs statt der Namen: Führen Sie id -u im Container und ls -ln für die Datei aus.

Eine per Bind-Mount eingebundene Datei behält den Besitz vom Host. Gehört die Datei auf dem Host Ihrem Benutzer und läuft der Prozess im Container unter einem anderen Benutzer, wird der Schreibzugriff im Container verweigert. sudo im Container ändert den Besitzer auf dem Host nicht. Beheben Sie das Problem auf dem Host. Setzen Sie den Besitzer auf die ID, unter der der Container läuft, oder starten Sie den Container unter der ID, der die Dateien bereits gehören. Images von linuxserver.io und ähnlichen Projekten stellen die Variablen PUID und PGID bereit, mit denen festgelegt wird, unter welchem Benutzer der Prozess läuft.

Zwei weitere Fälle bei Containern sollten Sie kennen. Ein mit :ro als schreibgeschützt eingebundener Mount oder ein mit --read-only gestarteter Container verweigert Schreibzugriffe unabhängig vom Besitz. cat /proc/mounts im Container zeigt das Flag an. Bei rootless Podman ordnet ein User-Namespace die Benutzer-IDs des Containers einem Bereich von Host-IDs zu. Eine Datei, die im Container scheinbar root gehört, gehört außerhalb des Containers Ihrem Benutzer ohne privilegierte Rechte.

Es gibt außerdem Änderungen, die zunächst erfolgreich sind und anschließend verschwinden. Eine Datei, die Sie in einem Container unter einem nicht eingebundenen Pfad ändern, liegt in der beschreibbaren Schicht des Containers. Diese Schicht wird verworfen, wenn der Container neu erstellt wird. Ändern Sie die Datei auf der Host-Seite des Mounts oder beim Erstellen des Images, wenn die Änderung dauerhaft bestehen bleiben soll.

Der Notausweg: Speichern Sie die Datei unter einem Pfad, für den Sie Schreibrechte haben

Versuchen Sie nicht, innerhalb des Editors zusätzliche Berechtigungen zu erlangen. Drücken Sie Ctrl-O, löschen Sie den Pfad an der Eingabeaufforderung, geben Sie einen Pfad unterhalb Ihres Home-Verzeichnisses wie /home/you/nginx.conf.new ein und drücken Sie Enter. Drücken Sie anschließend Ctrl-X, um den Editor zu verlassen. Ihre Arbeit liegt jetzt auf der Festplatte, gehört Ihnen, und der restliche Vorgang ist eine gewöhnliche Dateikopie.

sudo cp /home/you/nginx.conf.new /etc/nginx/nginx.conf
sudo nginx -t

Verwenden Sie hier cp statt mv. cp schreibt über die bereits vorhandene Datei. Dadurch bleiben Eigentümer, Gruppe und Berechtigungen dieser Datei erhalten. mv ersetzt sie auf demselben Dateisystem durch Ihre Datei. Dadurch gehört die Konfigurationsdatei in /etc Ihrem Benutzerkonto. Das ist das nächste Berechtigungsproblem, das Sie lösen müssen.

Prüfen Sie das Ergebnis mit dem Tool, dem die Datei zugeordnet ist, bevor Sie etwas neu laden. sudo nginx -t analysiert die nginx-Konfiguration, und sudo sshd -t analysiert die Konfiguration des SSH-Servers. Für zwei Dateien gibt es spezielle Editoren, die diesen gesamten Vorgang für Sie erledigen: sudo visudo für /etc/sudoers und crontab -e für Ihre eigenen Cron-Jobs. Beide bearbeiten eine temporäre Kopie, prüfen die Syntax und installieren die Datei nur, wenn sie erfolgreich analysiert werden kann.

FAQ

Sollte ich sudo nano oder sudoedit zum Bearbeiten einer Systemdatei verwenden?

Verwenden Sie sudoedit. Der Befehl kopiert die Datei in eine temporäre Kopie, deren Eigentümer Sie sind, startet den Editor unter Ihrem eigenen Benutzerkonto und schreibt das Ergebnis beim Beenden des Editors als root zurück. Der Editor selbst verfügt dadurch zu keinem Zeitpunkt über root-Berechtigungen. Setzen Sie SUDO_EDITOR, VISUAL oder EDITOR auf nano, um nano auszuwählen. sudo nano funktioniert ebenfalls. Dabei erhält ein interaktiver Editor für die Dauer der Sitzung root-Zugriff auf jeden Pfad im System. Ein einziger falsch eingegebener Dateiname an der Speicheraufforderung kann dadurch eine beschädigte Systemdatei erzeugen.

Benötige ich Schreibberechtigungen für das Verzeichnis, um eine Datei mit nano zu speichern?

Nicht bei einer bereits vorhandenen Datei. nano schreibt in die Datei selbst. Der Kernel prüft daher das Schreibbit der Datei und das Ausführungsbit jedes Verzeichnisses im Pfad. Das Schreibbit des Verzeichnisses ist erforderlich, wenn die Datei noch nicht existiert, weil ein neuer Name angelegt werden muss. Das gilt auch bei aktivierten Sicherungskopien oder Dateisperren, weil beide eine zweite Datei neben dem Original anlegen.

Der Eigentümer ist korrekt und der Datenträger ist nicht voll. Was kann den Schreibvorgang noch verhindern?

Vier Dinge kommen infrage. Das Dateisystem ist möglicherweise schreibgeschützt eingehängt. findmnt -no OPTIONS -T /etc/nginx/nginx.conf zeigt dies an. Die Datei kann das Attribut immutable besitzen. lsattr zeigt das Attribut an, und sudo chattr -i entfernt es. Solange es gesetzt ist, kann nicht einmal root in die Datei schreiben. Der Inode-Pool kann erschöpft sein, obwohl noch freier Speicherplatz vorhanden ist. df -i zeigt dies an. SELinux oder AppArmor kann den Schreibvorgang trotz passender Berechtigungsbits verweigern. Das Audit-Log protokolliert die Verweigerung für den von Ihnen verwendeten Pfad.

Wo speichere ich meine Änderungen, wenn die Datei überhaupt nicht gespeichert werden kann?

Drücken Sie Ctrl-O und geben Sie einen Pfad an, dessen Eigentümer Sie sind, beispielsweise unter Ihrem Home-Verzeichnis oder an einem anderen Ort, an dem Ihr Benutzer schreiben darf. Der Puffer bleibt im Speicher, sodass keine Ihrer Eingaben verloren geht. Kopieren Sie die gespeicherte Datei anschließend mit sudo cp an die richtige Stelle. Dabei bleiben Eigentümer und Berechtigungen der ursprünglichen Datei erhalten. Prüfen Sie die Datei danach mit dem eigenen Testbefehl des Dienstes, bevor Sie den Dienst neu laden.

Warum verschwinden meine Änderungen in einem Docker-Container?

Wenn der Pfad kein Mount ist, wird die Änderung in der beschreibbaren Schicht des Containers gespeichert. Diese Schicht wird verworfen, wenn der Container ersetzt wird. Bearbeiten Sie die Datei auf der Host-Seite eines Bind-Mounts oder eines Volumes, oder integrieren Sie sie in das Image. Wenn der Pfad ein Bind-Mount ist und das Speichern stattdessen verweigert wird, vergleichen Sie id -u innerhalb des Containers mit dem numerischen Eigentümer aus ls -ln. Die Datei behält ihren Eigentümer auf dem Host. Der Containerprozess muss mit diesem Eigentümer übereinstimmen.