7.3. Warum bekommt root 'permission denied'-Meldungen?

7.3.1

Wenn root eine "Permission denied"-Meldung bekommt, kann das mehrere Ursachen haben.

Der einfachste Grund ist schlicht und einfach, dass die aufgerufene Datei keine Ausführrechte hat. Beispiel:

root@host:~ $ ls -l ./irgendwas.txt
-rw-r--r--  1 root root 4711 2004-09-16 22:29 irgendwas.txt
root@host:~ $ ./irgendwas.txt
bash: ./irgendwas.txt: Permission denied.

Fehlende Verzeichnisrechte (x-bit in einem der übergeordneten Verzeichnisse nicht gesetzt) können zu einer ähnlichen Fehlermeldung führen, allerdings nicht bei root. Als User kann man diesen Fehler leicht nachprüfen, indem man per cd versucht, ins entsprechende Verzeichnis zu wechseln.

Eine weitere mögliche Fehlerursache ist, dass die betreffende Partition mit der noexec-Option gemountet ist. Zu kontrollieren ist das durch Lesen der Ausgabe von mount. Übrigens: Die Mountoptionen user und users implizieren noexec. Sollte das nicht gewünscht sein, kann man die Mountoption user,exec verwenden (die Reihenfolge ist wichtig!).

Ein weiteres Problem kann im Zusammenhang mit NFS-mounts auftreten - wenn auf dem NFS-Server die Option no_root_squash nicht gesetzt ist (das ist die Standardeinstellung) - in diesem Fall werden Zugriffe durch root auf den "anonymous"-User umgemappt, der üblicherweise keine (Schreib-)Rechte hat.

Ab SUSE Linux 10.1 kann auch AppArmor für fehlende Rechte verantwortlich sein - nachzulesen ist das in /var/log/audit/audit.log. Falls der Zugriff künftig erlaubt sein soll, kann man mit YaST2 das AppArmor-Profil anpassen.

Wenn diese Möglichkeiten geklärt sind und nicht zutreffen, bleibt noch die letzte und unangenehmste Möglichkeit. Dabei kann es vorkommen, dass bereits ls eine Fehlermeldung bringt:

root@host:~ $ ls -la /sbin/*fetch*
-bash: /sbin/rcfetchmail: Permission denied

Fehler in diesem Stadium deuten meist auf einen Defekt im Dateisystem hin. Ein fsck der betroffenen Partition ist dann dringend anzuraten.

Vor Reparaturen am Dateisystem empfiehlt es es sich grundsätzlich, ein Backup anzufertigen, da z. B. reiserfsck --rebuild-tree schon zu einigen Nebenwirkungen geführt hat.