nginx antwortet mit 403 Forbidden? Meist fehlt die Index-Datei, das Verzeichnislisting ist aus oder die Dateirechte stimmen nicht. So löst du es.
Aufwand:
ca. 15 Min.
Voraussetzung:
Root- bzw. sudo-Zugriff auf den Server
Gilt für:
nginx als Webserver für statische oder dynamische Inhalte
Das Symptom
Statt der erwarteten Seite liefert nginx nur eine kurze 403 Forbidden-Fehlerseite.
Manchmal betrifft es die ganze Domain, manchmal nur ein bestimmtes Verzeichnis oder
eine einzelne Datei, während der Rest der Seite normal lädt. Die Datei liegt
nachweislich am richtigen Ort – und nginx weigert sich trotzdem beharrlich, sie
herauszurücken.
Die „Layer 8“-Wahrheit
403 ist keine Verwechslung mit „nicht gefunden“ – das wäre ein 404. 403 heißt: Die
Ressource ist da, nginx darf sie nur nicht ausliefern. Und das hat fast immer einen
von zwei Gründen. Der erste ist banal und beabsichtigt: Du rufst ein Verzeichnis auf,
nginx sucht darin nach einer Index-Datei, findet keine – und weil das Auflisten von
Verzeichnisinhalten standardmäßig ausgeschaltet ist, verweigert es die Ausgabe, statt
dein Dateisystem preiszugeben. Der zweite Grund sitzt eine Ebene tiefer im
Dateisystem: Der nginx-Prozess läuft als eigener, unprivilegierter Nutzer und braucht
Leserecht auf die Datei sowie Ausführungsrecht auf jedes Verzeichnis im Pfad dorthin.
Fehlt es an nur einer Stelle – oft, weil Dateien frisch aus dem Homeverzeichnis
kopiert wurden – ist Schluss. Das Errorlog nennt den Fall wörtlich. Der Reflex,
kurzerhand chmod 777 zu setzen, macht die Seite zwar wieder erreichbar, reißt dabei
aber ein Sicherheitsloch auf, das größer ist als das ursprüngliche Problem.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Das Errorlog lesen
Zuerst die genaue Meldung holen. Sie unterscheidet die beiden Hauptfälle sofort: „directory index of ... is forbidden“ heißt fehlender Index bei ausgeschaltetem Listing, „Permission denied“ heißt fehlende Dateirechte:
tail -n 50 /var/log/nginx/error.log
2.
Die Dateirechte im ganzen Pfad prüfen
nginx braucht Leserecht auf die Datei und Ausführungsrecht auf jedes Verzeichnis darüber – fehlt es irgendwo im Pfad, gibt es 403. namei zeigt die Rechte Ebene für Ebene, statt nur das letzte Verzeichnis zu betrachten:
namei -l /var/www/html/index.html
3.
Besitzer und Rechte gezielt setzen
Fehlt dem Webserver-Nutzer der Zugriff, Besitzer und Rechte sauber setzen – Verzeichnisse brauchen 755, Dateien 644. Den passenden Nutzer je nach Distribution wählen (www-data unter Debian/Ubuntu, nginx unter RHEL/Fedora):
Rufst du ein Verzeichnis auf, sucht nginx standardmäßig nach index.html. Fehlt sie und ist autoindex nicht eingeschaltet, folgt 403 – das ist beabsichtigt, kein Fehler. Entweder die erwartete Index-Datei bereitstellen oder, nur wo gewollt, das Listing bewusst aktivieren:
location /downloads/ {
autoindex on;
}
5.
SELinux-Kontext prüfen
Auf RHEL, Fedora und AlmaLinux kann trotz korrekter Unix-Rechte ein falscher SELinux-Kontext den Zugriff blockieren – etwa nach dem Verschieben von Dateien aus dem Homeverzeichnis. Den erwarteten Kontext wiederherstellen:
restorecon -Rv /var/www/html
6.
Konfiguration testen und neu laden
Nach Änderungen an der Konfiguration erst die Syntax prüfen, dann neu laden – ein kaputtes Reload legt sonst die ganze Seite lahm:
nginx -t
systemctl reload nginx
Häufige Fragen (FAQ)
?Warum bekomme ich 403, obwohl die Datei existiert?
403 heißt „Zugriff verweigert“, nicht „nicht gefunden“ – die Datei ist also da, nginx darf sie nur nicht ausliefern. Zwei Ursachen dominieren: Entweder rufst du ein Verzeichnis ohne Index-Datei auf, und da Verzeichnislisting standardmäßig aus ist, verweigert nginx die Ausgabe. Oder der nginx-Prozess (meist der Nutzer www-data oder nginx) hat schlicht keine Leserechte auf die Datei oder ein Verzeichnis im Pfad dorthin.
?Sollte ich einfach chmod 777 auf das Webverzeichnis setzen?
Nein – das macht den gesamten Inhalt für jeden auf dem System beschreibbar und ist ein klassisches Sicherheitsloch. nginx braucht nur Leserecht auf die Dateien und Ausführungsrecht (das „x“) auf jedes Verzeichnis im Pfad. Setze Besitzer und Rechte gezielt, statt mit dem Vorschlaghammer alles freizugeben.
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.
Nach dem Verschieben von Dateien meldet ein Dienst 'Permission denied', obwohl die Rechte stimmen? Der SELinux-Kontext fehlt, restorecon repariert ihn.
Die Sortierbibliothek des Betriebssystems hat sich geändert. PostgreSQL warnt vor einem Versions-Konflikt — Indizes auf Textspalten sind dann unbrauchbar.
nginx liefert 504 Gateway Timeout? Der Upstream antwortet nicht rechtzeitig, bevor nginx aufgibt. So findest du die Ursache und setzt Timeouts sinnvoll.
nginx liefert 502 Bad Gateway? Der Upstream antwortet nicht wie erwartet. So findest du Dienst-, Timeout- und Berechtigungsursachen und reparierst sie.