Nginx 403 für alle Dateien verboten

Ich habe nginx mit PHP-FPM auf einer CentOS 5-Box installiert, habe aber Schwierigkeiten, es für alle meine Dateien bereitzustellen - ob PHP oder nicht.

Nginx wird als www-data: www-data ausgeführt, und die Standardwebsite "Willkommen bei Nginx auf EPEL" (im Besitz von root: root mit 644 Berechtigungen) wird problemlos geladen.

Die nginx-Konfigurationsdatei enthält eine include-Direktive für /etc/nginx/sites-enabled/*.conf, und ich habe eine Konfigurationsdatei example.com.conf , also:

server {
 listen 80;

 Virtual Host Name
 server_name www.example.com example.com;


 location / {
   root /home/demo/sites/example.com/public_html;
   index index.php index.htm index.html;
 }

 location ~ \.php$ {
  fastcgi_pass   127.0.0.1:9000;
  fastcgi_index  index.php;
  fastcgi_param  PATH_INFO $fastcgi_script_name;
  fastcgi_param  SCRIPT_FILENAME  /home/demo/sites/example.com/public_html$fastcgi_script_name;
  include        fastcgi_params;
 }
}

Obwohl public_html im Besitz von www-data: www-data mit 2777 Dateiberechtigungen ist, liefert diese Site keinen Inhalt -

 [error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"

Ich habe zahlreiche andere Posts mit Benutzern gefunden, die 403s von nginx erhalten, aber die meisten, die ich gesehen habe, betreffen entweder komplexere Setups mit Ruby / Passenger (was mir in der Vergangenheit tatsächlich gelungen ist) oder erhalten nur Fehler, wenn das Upstream-PHP -FPM ist beteiligt, daher scheinen sie wenig hilfreich zu sein.

Habe ich hier etwas Dummes getan?

Eine häufig übersehene Berechtigungsanforderung besteht darin, dass ein Benutzer in jedem übergeordneten Verzeichnis einer Datei x Berechtigungen benötigt, um auf diese Datei zugreifen zu können. Überprüfen Sie die Berechtigungen für /, / home, / home / demo usw. für den Zugriff auf www-data x. Ich vermute, dass / home wahrscheinlich 770 ist und www-data nicht durch chdir kann, um zu einem Unterverzeichnis zu gelangen. Wenn dies der Fall ist, versuchen Sie es mit chmod o + x / home (oder mit einem beliebigen Verzeichnis, das die Anforderung ablehnt).

BEARBEITEN: Um alle Berechtigungen für einen Pfad einfach anzuzeigen, können Sie verwenden namei -om /path/to/check

Wenn permission deniednach dem Überprüfen der Berechtigungen der übergeordneten Ordner weiterhin angezeigt wird, kann es sein, dass SELinux den Zugriff einschränkt.

So überprüfen Sie, ob SELinux ausgeführt wird:

# getenforce

So deaktivieren Sie SELinux bis zum nächsten Neustart:

# setenforce Permissive

Starten Sie Nginx neu und prüfen Sie, ob das Problem weiterhin besteht. Damit nginx Ihre www - Verzeichnis dienen (stellen Sie sicher , schalten Sie SELinux wieder auf , bevor diese zu testen. Dh setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Siehe meine Antwort hier für weitere Details

Ich habe dieses Problem durch Hinzufügen von Benutzereinstellungen gelöst.

in nginx.conf

worker_processes 4;
user username;

Ändern Sie den 'Benutzernamen' mit dem Linux-Benutzernamen.

Ich habe diesen Fehler und habe ihn schließlich mit dem folgenden Befehl behoben.

restorecon -r /var/www/html

Das Problem wird verursacht, wenn Sie etwas von einem Ort zum anderen bewegen. Der Selinux-Kontext des Originals bleibt beim Verschieben erhalten. Wenn Sie also etwas in / home oder / tmp entpacken, wird ein Selinux-Kontext angezeigt, der seinem Speicherort entspricht. Jetzt mv das in / var / www / html und es nimmt den Kontext an, der besagt, dass es in / tmp oder / home gehört und httpd von der Richtlinie nicht auf diese Dateien zugreifen darf.

Wenn Sie die Dateien kopieren, anstatt sie zu bearbeiten, wird der Selinux-Kontext entsprechend dem Speicherort zugewiesen, an den Sie kopieren, und nicht, woher er kommt. Durch Ausführen von restorecon wird der Kontext auf den Standard zurückgesetzt und ebenfalls behoben.

Ich habe verschiedene Fälle ausprobiert und erst als der Besitzer auf nginx ( chown -R nginx:nginx "/var/www/myfolder") eingestellt war, begann es wie erwartet zu funktionieren.

Wenn Sie SELinux verwenden, geben Sie einfach Folgendes ein:

sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/

Dadurch wird das Berechtigungsproblem behoben.

Alte Frage, aber ich hatte das gleiche Problem. Ich habe jede Antwort oben ausprobiert, nichts hat funktioniert. Was es für mich behoben hat, war das Entfernen der Domain und das erneute Hinzufügen. Ich verwende Plesk und habe Nginx installiert, nachdem die Domain bereits vorhanden war.

Habe aber zuerst eine lokale Sicherung in / var / www / backups durchgeführt. So konnte ich die Dateien leicht zurückkopieren.

Seltsames Problem ....

Wir hatten das gleiche Problem mit Plesk Onyx 17. Anstatt mit Rechten usw. herumzuspielen, bestand die Lösung darin, nginx-Benutzer zur psacln-Gruppe hinzuzufügen, in der sich alle anderen Domaininhaber (Benutzer) befanden:

usermod -aG psacln nginx

Jetzt hat nginx das Recht, auf .htaccess oder eine andere Datei zuzugreifen, die zur ordnungsgemäßen Anzeige des Inhalts erforderlich ist.

Stellen Sie andererseits auch sicher, dass sich Apache in der psaserv-Gruppe befindet, um statischen Inhalt bereitzustellen:

usermod -aG psaserv apache

Und vergessen Sie nicht, Apache und Nginx in Plesk danach neu zu starten! (und Seiten mit Strg-F5 neu laden)

Ich habe mich in eine leichte Variante dieses Problems vertieft, indem ich den setfaclBefehl versehentlich ausgeführt habe. Ich rannte:

sudo setfacl -m user:nginx:r /home/foo/bar

Ich habe diese Route zugunsten des Hinzufügens nginxzur fooGruppe aufgegeben , aber diese benutzerdefinierte ACL hat die Versuche von nginx, auf die Datei zuzugreifen, vereitelt. Ich habe es durch Laufen geklärt:

sudo setfacl -b /home/foo/bar

Und dann konnte nginx auf die Dateien zugreifen.

Wenn Sie PHP verwenden, stellen Sie sicher, dass die indexNGINX-Direktive im Serverblock eine index.php enthält:

index index.php index.html;

Weitere Informationen finden Sie in der Indexrichtlinie in der offiziellen Dokumentation.

Ich hatte das gleiche Problem, aber die oben genannten Lösungen haben nicht geholfen.

Nach vielen Kämpfen fand ich heraus, dass sestatus so eingestellt war, dass alle Ports blockiert wurden, und dass alle Probleme gelöst wurden, indem es auf " freizügig" gesetzt wurde.

sudo setenforce 0

Hoffe das hilft jemandem wie mir.