Permission denied unter Linux: 10 Fälle einschließlich /dev/null
Permission denied ist ein Linux-Fehler, der erscheint, wenn dein aktuelles Konto keine Berechtigung hat, diese Datei, diesen Ordner oder diesen Befehl zu verwenden. Wähle deinen Fall anhand des Befehlsnamens und des Pfads am Anfang der Fehlerzeile, prüfe mit ls -l Rechte und Eigentümer und führe es mit den passenden Rechten oder dem passenden Konto erneut aus, dann ist das Problem gelöst.
Die folgende Ausgabe stammt vom root-Konto eines AlmaLinux-9.8-Servers und von einem normalen Konto eines Debian-12-Servers; Konto- und Hostnamen sowie die Uhrzeiten in der /dev/null-Ausgabe sind Beispielwerte.
1️⃣ Ursache von Permission denied finden
Eine Fehlerzeile endet in der Form [Befehl: Ziel: Permission denied], und am Befehlsnamen und Pfad davor erkennst du, wo es blockiert wurde. Wähle im Diagramm unten die Fehlermeldung, die der auf deinem Bildschirm ähnelt, dann siehst du den Befehl, den du zuerst prüfen solltest, und die Stelle in diesem Artikel, die du lesen solltest.
2️⃣ Häufige Permission-denied-Fehler
🔲 Lese- und Schreibrechte für Dateien
Zum Lesen einer Datei braucht das Konto das Leserecht (r), zum Ändern oder Neuanlegen das Schreibrecht (w). secret.txt mit den Rechten 600 kann nur ihr Eigentümer root lesen und schreiben.
ls -l secret.txt-rw------- 1 root root 16 Oct 29 00:29 secret.txtrunuser -u daemon -- cat secret.txtcat: secret.txt: Permission deniedAls ein anderes Konto, daemon, dieselbe Datei las, wurde es sofort abgelehnt. Beim Anlegen einer Datei in einem Ordner ohne Schreibrecht kommt derselbe Fehler: Auf dem Debian-12-Server wurde touch mit einem normalen Konto in einem lock-Ordner mit den Rechten 000 blockiert.
touch ~/touchtest/lock/x.txttouch: cannot touch '/home/user/touchtest/lock/x.txt': Permission deniedSieh in der ersten Spalte von ls -l der Reihe nach für Eigentümer, Gruppe und andere Konten nach, ob r und w vorhanden sind, und gib dann nur dem Konto, das sie braucht, mit chmod Rechte dazu oder ändere mit chown den Eigentümer.
🔲 Durchgangsrecht für Ordner
Auch wenn die Dateirechte stimmen, erreichst du eine Datei nicht, wenn einem Ordner mitten im Pfad das Recht x fehlt. Bei einem Ordner ist x das Recht, ihn zu durchqueren und hineinzugehen, und r das Recht, die Liste der Namen darin zu lesen.
ls -ld web web/cssdrw-r--r-- 3 root root 35 Oct 29 00:29 web
drw-r--r-- 2 root root 23 Oct 29 00:29 web/cssrunuser -u daemon -- ls -l webls: cannot access 'web/css': Permission denied
ls: cannot access 'web/index.html': Permission denied
total 0
d????????? ? ? ? ? ? css
-????????? ? ? ? ? ? index.htmlDer Ordner web hat nur r, daher konnte daemon die Namen darin, css und index.html, lesen, aber ohne x blieben Rechte und Größen als Fragezeichen stehen. Umgekehrt blockierte der Ordner site, der x, aber kein r hat, die Auflistung, während eine Datei, deren Namen man kannte, gelesen werden konnte.
ls -ld sitedrwx--x--x 2 root root 24 Oct 29 00:29 siterunuser -u daemon -- ls sitels: cannot open directory 'site': Permission deniedrunuser -u daemon -- cat site/index.html<h1>index</h1>Ist der Pfad lang, prüfe mit ls -ld von oben Ordner für Ordner, ob x vorhanden ist, und gib dem blockierten Ordner nur das x, das das Konto zum Durchqueren braucht.
🔲 Ausführungsrecht
Um ein Skript als ./Dateiname auszuführen, braucht die Datei das Recht x. deploy.sh mit den Rechten 644 wurde abgelehnt.
ls -l deploy.sh-rw-r--r-- 1 root root 8 Oct 29 00:29 deploy.sh./deploy.shbash: line 1: ./deploy.sh: Permission deniedNachdem chmod u+x dem Eigentümer x gegeben hatte, änderte sich die erste Spalte zu [-rwxr--r--].
chmod u+x deploy.shls -l deploy.sh-rwxr--r-- 1 root root 8 Oct 29 00:29 deploy.shWird das Ausführen trotz Recht x abgelehnt, prüfe, ob das Dateisystem, auf dem die Datei liegt, mit noexec eingehängt ist.
🔲 Informationen lesen, die root vorbehalten sind
Ein normales Konto kann keine Informationen lesen, die das System root vorbehält, etwa von root gestartete Prozesse oder Passwortinformationen anderer Konten. Auf dem Debian-12-Server ergab das Öffnen des fd-Ordners von Prozess 1 mit einem normalen Konto einen Rechtefehler.
ls /proc/1/fdls: cannot open directory '/proc/1/fd': Permission deniedchage -l daemonchage: Permission denied.Die Passwortablaufdaten eines anderen Kontos wurden aus demselben Grund blockiert; /etc/shadow, das sie enthält, ist eine Datei, die normale Benutzer nicht lesen dürfen. Bei solchen Fehlern erweiterst du nicht die Rechte, sondern führst den Befehl mit sudo oder als root erneut aus.
🔲 Wenn > trotz sudo blockiert wird
sudo führt nur den dahinter geschriebenen Befehl als root aus, während das Öffnen einer Datei für die Umleitung (>) die Shell des aktuellen Kontos übernimmt, bevor der Befehl läuft. Leitest du daher die Ausgabe von sudo echo in eine Datei um, die nur root schreiben darf, beginnt die Fehlerzeile mit dem Shell-Namen in der Form [bash: Dateipfad: Permission denied].
sudo echo x > /root/test.txtUm auch die Umleitung als root auszuführen, umschließt du die ganze Zeile mit sh -c und führst so die Shell selbst mit sudo aus; auch das offizielle sudo-Handbuch nennt ein Beispiel, bei dem in sh -c ausgeführt wird, damit die Umleitung funktioniert.
sudo sh -c 'echo x > /root/test.txt'tee nimmt die Standardeingabe entgegen und schreibt sie direkt in die angegebenen Dateien; führst du tee mit sudo aus, öffnet also tee mit root-Rechten die Datei. tee gibt das Empfangene außerdem noch einmal auf dem Bildschirm aus.
echo x | sudo tee /root/test.txt🔲 SSH-Anmeldung abgelehnt
Steht vor Permission denied [Konto@Serveradresse:] und in Klammern eine Authentifizierungsmethode wie publickey, wurde die Anmeldung im Authentifizierungsschritt abgelehnt, und die Stelle, die du prüfen musst, ist eine andere als bei Dateirechten. Auf dem Server steht StrictModes von sshd auf dem Standardwert yes, daher prüft sshd vor dem Annehmen der Anmeldung Rechte und Eigentümer von Home-Ordner und Dateien dieses Kontos. Kann ein anderes Konto auch nur in einen davon schreiben, den Home-Ordner, den Ordner ~/.ssh oder ~/.ssh/authorized_keys, verwendet sshd diese Schlüsseldatei nicht; prüfe also mit ls -ld, dass keiner der drei anderen Konten das Recht w gibt.
⌨️ Permission-denied-Simulator
Der Simulator unten startet mit dem root-Konto; mit runuser wirst du zu einem anderen Konto, daemon, und kannst selbst sehen, welche Ausgabe kommt, wenn Lesen von Dateien, Durchqueren von Ordnern und das Ausführungsrecht blockiert werden.
3️⃣ Seltene Permission-denied-Fehler
Wirst du abgelehnt, obwohl die Rechtespalte stimmt, hat etwas außerhalb der Rechtebits blockiert, etwa eine SELinux-Richtlinie oder ein noexec-Mount. Wird das Ausführen sogar als root abgelehnt, prüfe, ob die Datei überhaupt kein x-Bit hat.
Auf einem Server mit aktiviertem SELinux erscheint Permission denied, wenn eine SELinux-Richtlinie blockiert, auch wenn die Rechtebits stimmen; prüfe in diesem Fall zuerst die Ablehnungseinträge von SELinux. Auf Servern, auf denen der audit-Daemon läuft, landen Ablehnungen als [avc: denied] in /var/log/audit/audit.log, zusammen mit der blockierten Aktion, dem Befehlsnamen (comm) und dem Zielnamen (name).
Prüfe mit getenforce, ob SELinux aktiv ist, und führe als root ausearch aus, um die Ablehnungen von heute zu sehen.
getenforceausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts todayAuch der rsync-Daemon lieferte beim Empfangen [Permission denied (13)]; dort blockierte ebenfalls SELinux den Zugriff auf den Modulpfad.
Auf einem mit noexec eingehängten Dateisystem lassen sich Dateien nicht direkt ausführen; selbst wenn ls -l ein x zeigt, werden sie mit [bash: Skriptpfad: Permission denied] abgelehnt. Gibst du den Ordner an findmnt -T, siehst du, wo er eingehängt ist und mit welchen Optionen; steht noexec bei den Optionen, ist es dieser Fall.
findmnt -T /tmp -o TARGET,OPTIONSroot überspringt die meisten Rechteprüfungen, aber das Ausführen ist nur erlaubt, wenn mindestens einer von Eigentümer, Gruppe oder anderen Konten x hat. Deshalb wird ein Skript ganz ohne x abgelehnt, auch wenn root es mit ./ ausführt.
Als root deploy.sh mit der ersten Spalte [-rw-r--r-- 1 root root] mit ./ ausführte, kam [bash: line 1: ./deploy.sh: Permission denied].
🔲 Wenn /dev/null zu einer normalen Datei geworden ist
Erscheinen direkt nach der SSH-Anmeldung mit einem normalen Konto die Zeilen unten nacheinander noch vor dem Shell-Prompt, prüfe zuerst, ob /dev/null, das Zeichengerät, mit dem alle Konten Ausgaben verwerfen, zu einer normalen Datei von root geworden ist. Die Zahl der Zeilen hängt pro Server davon ab, wie viele profile-Skripte bei der Anmeldung gelesen werden, und auf demselben Server kam der Fehler nach dem Wechsel zu root nicht.
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
...ls -l /dev/null-rw-r--r-- 1 root root 55 Jan 10 09:00 /dev/nullstat -c %F /dev/nullregular fileDie erste Spalte war [-rw-r--r--] und an der Stelle der Größe stand 55: Fehlertext, den andere Befehle verworfen hatten, hatte sich in der Datei angesammelt. Läuft eine Aufräum-Befehlszeile, die die Form unten enthält, als root, löscht rm die Gerätedatei, und die Umleitung 2>/dev/null des nächsten Befehls legt unter demselben Namen eine neue normale Datei von root an.
rm -f /dev/null 2>/dev/nullFühre die Zeile unten als root aus. Legst du das neue Gerät unter einem Namen daneben an und überschreibst dann mit mv, gibt es keinen Moment, in dem der Name fehlt, sodass zwischen Löschen und Anlegen keine Lücke bleibt, in der eine andere Umleitung wieder eine normale Datei anlegt.
mknod -m 666 /dev/null.new c 1 3 && mv -f /dev/null.new /dev/null && ls -l /dev/nullcrw-rw-rw- 1 root root 1, 3 Jan 10 09:05 /dev/nullstat -c %F /dev/nullcharacter special fileDas [c 1 3] bei mknod ist die Nummer von /dev/null in der Gerätenummernliste des Kernels. Nach der Wiederherstellung lief auch echo x > /dev/null mit einem normalen Konto ohne Fehler durch. Ein Neustart kann es ebenfalls zurückbringen, aber die eine Zeile oben, die den Server nicht anhält, ist schneller.
| Prüfen | Vor der Korrektur | Nach der Korrektur |
|---|---|---|
| Erste Spalte von ls -l | -rw-r--r-- | crw-rw-rw- |
| Größe in ls -l | 55 | 1, 3 |
| stat -c %F | regular file | character special file |
| Schreiben als normales Konto | Permission denied | Kein Fehler |
Leite Ausgaben, die du verwerfen willst, nur bis >/dev/null oder 2>/dev/null weiter, und setze /dev/null außer bei der Wiederherstellung nie als Ziel von rm oder mv ein.
🔢 FAQ & empfohlene Inhalte
Webserver · 403
Apache-403-Fehler nach der APM-Installation (403 Forbidden)
Ein Artikel über einen Fall, in dem der Webserver den Web-Ordner nicht lesen konnte, Permission denied in error_log hinterließ und 403 zeigte.
Webserver · 503
503-Fehler nach der APM-Installation
Ein Artikel, der mit error.log einen Fall prüft, in dem Apache sich nicht mit dem php-fpm-Socket verbinden konnte und 503 lieferte.
ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt(bei Aktionsrabatten sinkt er ↓), steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.