Permission denied unter Linux: 10 Fälle einschließlich /dev/null

TestumgebungRHEL-FamilieAlmaLinux 9.8root-KontoDebian 12 normales KontoGeprüft am 2026-11-05
Ursache von Permission denied finden

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.

🧭 Deinen Fall anhand der Fehlermeldung wählen
Erklär-Diagramm
🧭 Fehlermeldung
Fehlermeldungcat: secret.txt: Permission deniedls: cannot access 'web/index.html': Permission denied./deploy.sh: Permission deniedls: cannot open directory '/proc/1/fd': Permission deniedbash: /root/test.txt: Permission denieduser@server1: Permission denied (publickey)(13)Permission denied-bash: /dev/null: Permission denied
➜
Zuerst prüfenls -l secret.txtls -ld webls -l deploy.shidsudo sh -cRechte von Home-Ordner und Dateiengetenforce · findmntls -l /dev/null
➜
Stelle in diesem Artikel🔲 Lese- und Schreibrechte für Dateien🔲 Durchgangsrecht für Ordner🔲 Ausführungsrecht🔲 Informationen lesen, die root vorbehalten sind🔲 Wenn > trotz sudo blockiert wird🔲 SSH-Anmeldung abgelehnt3️⃣ Seltene Permission-denied-Fehler🔲 Wenn /dev/null zu einer normalen Datei geworden ist
Wird ein Befehl abgelehnt, der eine Datei liest oder ändert, prüfe zuerst die Rechte r und w dieser Datei und ihren Eigentümer.
Erscheint der Name eines Ordners mitten im Pfad im Fehler, prüfe, ob dieser Ordner das Recht x hat.
Wird das direkte Ausführen eines Skripts abgelehnt, prüfe, ob die Datei das Recht x hat.
Wird das Lesen von Systeminformationen mit einem normalen Konto blockiert, prüfe das aktuelle Konto und führe es als root erneut aus.
Wird eine Umleitung mit > trotz sudo blockiert, führe auch die Umleitung als root aus.
Stehen Konto und Serveradresse vor dem Fehler, wurde die Anmeldung bei der Authentifizierung abgelehnt.
Wird es abgelehnt, obwohl die Rechtespalte stimmt oder du es als root ausgeführt hast, prüfe SELinux, noexec und die Ausführungsbits.
Erscheint diese Zeile direkt nach der Anmeldung immer wieder, prüfe, ob /dev/null zu einer normalen Datei geworden ist.

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.txt
runuser -u daemon -- cat secret.txt
cat: secret.txt: Permission denied

Als 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.txt
touch: cannot touch '/home/user/touchtest/lock/x.txt': Permission denied

Sieh 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.

web/ ── drw-r--r-- · r ja · x nein → hier blockiert
css/ ── Name sichtbar, Rechte · Größe ?
style.css ── nicht erreichbar
index.html ── Name sichtbar, Rechte · Größe ?
ls -ld web web/css
drw-r--r-- 3 root root 35 Oct 29 00:29 web
drw-r--r-- 2 root root 23 Oct 29 00:29 web/css
runuser -u daemon -- ls -l web
ls: cannot access 'web/css': Permission denied
ls: cannot access 'web/index.html': Permission denied
total 0
d????????? ? ? ? ?            ? css
-????????? ? ? ? ?            ? index.html

Der 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 site
drwx--x--x 2 root root 24 Oct 29 00:29 site
runuser -u daemon -- ls site
ls: cannot open directory 'site': Permission denied
runuser -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.sh
bash: line 1: ./deploy.sh: Permission denied

Nachdem chmod u+x dem Eigentümer x gegeben hatte, änderte sich die erste Spalte zu [-rwxr--r--].

chmod u+x deploy.sh
ls -l deploy.sh
-rwxr--r-- 1 root root 8 Oct 29 00:29 deploy.sh

Wird 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/fd
ls: cannot open directory '/proc/1/fd': Permission denied
chage -l daemon
chage: 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.txt

Um 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.

Permission-denied-Simulatorcoreutils 8.32
[root@server1 work]#
Läuft nur in deinem Browser. Er startet mit dem root-Konto; setzt du cat oder ls hinter runuser -u daemon --, siehst du die Ausgabe als anderes Konto, daemon.

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.

getenforce
ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today

Auch 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,OPTIONS

root ü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/null
stat -c %F /dev/null
regular file

Die 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/null

Fü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/null
crw-rw-rw- 1 root root 1, 3 Jan 10 09:05 /dev/null
stat -c %F /dev/null
character special file

Das [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üfenVor der KorrekturNach der Korrektur
Erste Spalte von ls -l-rw-r--r--crw-rw-rw-
Größe in ls -l551, 3
stat -c %Fregular filecharacter special file
Schreiben als normales KontoPermission deniedKein 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

Beim Schreiben auf ein schreibgeschützt eingehängtes Dateisystem erscheint [Read-only file system]; das ist ein anderer Fehler (EROFS) als Permission denied. Prüfe dann vor den Rechten, mit welchen Optionen dieses Dateisystem eingehängt ist.

Öffnest du Lesen, Schreiben und Ausführen für alle Konten, verschwindet dieses Permission denied, aber dann können auch andere Konten die Datei ändern. Nur dem Konto, das es braucht, Rechte zu geben oder den Eigentümer zu ändern, hält den Bereich enger.

Nur die Rechte zu erweitern lässt Permission denied verschwinden, aber /dev/null bleibt eine normale Datei, sodass sich verworfene Ausgaben weiter darin ansammeln. Als Gerät wiederhergestellt ist es erst, wenn stat wieder character special file meldet.

ℹ️ 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Beweisen Sie, dass Sie ein Mensch sind: 5   +   5   =