it-swarm.com.de

Nginx: stat () fehlgeschlagen (13: Berechtigung verweigert)

Ich verwende die Standardkonfiguration, während ich das spezifische Verzeichnis mit nginx auf meinem Ubuntu 12.04-Computer hinzufüge. 

server {
        #listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default ipv6only=on; ## listen for ipv6

        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to index.html
                root /username/test/static;
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }
...

...
}

Ich möchte nur einen einfachen statischen Nginx-Server, um Dateien aus diesem Verzeichnis heraus bereitzustellen. Ich überprüfe jedoch den error.log

2014/09/10 16:55:16 [crit] 10808#0: *2 stat() "/username/test/static/index.html" failed (13: Permission denied), client:, server: localhost, request: "GET /favicon.ico HTTP/1.1", Host: "domain"
2014/09/10 16:55:16 [error] 10808#0: *2 rewrite or internal redirection cycle while internally redirecting to "/index.html

Ich habe bereits chown -R www-data:www-data auf /username/test/static gemacht, ich habe sie auf chmod 755 eingestellt. Ich weiß nicht, was noch eingestellt werden muss.

80
user299709

Nginx arbeitet innerhalb des Verzeichnisses. Wenn Sie also vom Nginx-Benutzer keine cd in dieses Verzeichnis einbinden können, schlägt dies fehl (wie auch der Befehl stat in Ihrem Protokoll). Stellen Sie sicher, dass der www-usercd den ganzen Weg zum /username/test/static kann. Sie können durch Ausführen bestätigen, dass stat fehlschlägt oder erfolgreich ist

Sudo -u www-data stat /username/test/static

In Ihrem Fall liegt hier wahrscheinlich das /username-Verzeichnis vor. Normalerweise hat www-data keine Berechtigungen für cd für die Basisverzeichnisse anderer Benutzer.

Die beste Lösung wäre in diesem Fall, www-data zur Gruppe username hinzuzufügen:

gpasswd -a www-data username

und stellen Sie sicher, dass die Gruppe username alle Verzeichnisse entlang des Pfads eingeben kann:

chmod g+x /username && chmod g+x /username/test && chmod g+x /username/test/static

Starten Sie nginx neu, damit Ihre Änderungen funktionieren

nginx -s reload
148
Maciej Sz

Ich hatte gerade das gleiche Problem mit einer CentOS 7-Box. 

Anscheinend würde ich Selinux treffen. Das Umgehen von Selinux in den permissiven Modus (setenforce permissive) hat das Problem vorerst gelöst. Ich versuche es mit einer korrekten Lösung.

66

Auf CentOS 7.0 hatte ich dieses Access Deined-Problem, das durch SELinux verursacht wurde, und diese Schritte haben das Problem behoben:

yum install -y policycoreutils-devel
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp

Update: Nur eine Randnotiz aus dem, was ich bei der Verwendung von virtuellen Linux-Servern von digitalocean gelernt habe oder wie sie Droplets genannt werden. Für die Verwendung von SELinux ist ausreichend RAM erforderlich. Es ist höchstwahrscheinlich so, als würden Sie manage SELinux auf einem Droplet mit weniger als 2 GB RAM nicht ausführen können.

30
Achilles

Nginx muss + x Zugriff auf alle Verzeichnisse haben, die zum Stammverzeichnis der Site führen. 

Stellen Sie sicher, dass Sie + x für alle Verzeichnisse im Pfad zum Stammverzeichnis der Site haben. Wenn das Site-Stammverzeichnis beispielsweise/home/username/siteroot lautet:

chmod +x /home/
chmod +x /home/username
chmod +x /home/username/siteroot
26
Sairam Krish

Möglicherweise haben Sie Security-Enhanced Linux ausgeführt. Fügen Sie daher eine Regel für das hinzu. Ich hatte Berechtigung 13-Fehler, obwohl Berechtigungen festgelegt wurden und Benutzer vorhanden waren.

chcon -Rt httpd_sys_content_t /username/test/static

16
Artjom Kurapov

Symptom: 

Bilder konnten nicht in die WordPress-Medienbibliothek hochgeladen werden.

Ursache:

(CentOS) yum update

Error:

2014/10/22 18:08:50 [crit] 23286#0: *5332 open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied), client: 1.2.3.4, server: _, request: "POST /wp-admin/media-new.php HTTP/1.1", Host: "example.com", referrer: "http://example/wp-admin/media-new.php"

Lösung:

chown -R www-data:www-data /var/lib/nginx

3
PJ Brunet

Standardmäßig befinden sich die statischen Daten bei der Installation von nginx in/var/www/html. Sie können also einfach Ihren statischen Ordner in/var/html/kopieren und die 

root /var/www/<your static folder>

in ngix.conf (oder/etc/nginx/sites-available/default)

Das hat für mich auf Ubuntu funktioniert, aber ich denke, es sollte für andere Distros nicht viel anders sein. 

Ich hoffe es hilft. 

2
Patrik Bego

In meinem Fall war der Ordner, der die Dateien lieferte, ein symbolischer Link zu einem anderen Ordner, der mit erstellt wurde

ln -sf /Origin /var/www/destination

Obwohl die Berechtigungen (Benutzer und Gruppe) für den Zielordner (der symbolische Link) korrekt waren, hatte ich immer noch den Fehler, da Nginx auch Berechtigungen für die gesamte Hierarchie des Origin-Ordners benötigte.

Ändern Sie Ihre nginx.confuser-Eigenschaft in www-static-Dateien.

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user your_user_name;

# same other config
0
lonny

Ich habe dieses Problem angetreten und dieses Problem gelöst, um nginx-Benutzern Berechtigungen zu erteilen und Folgendes zu gruppieren:

chown -R nginx:nginx /username/test/static
0
julian salas

Ich hatte das gleiche Problem, ich benutze Plesk Onyx 17 mit Centos7. Ich konnte diesen Fehler in proxy_error_log unter den Protokollen der betroffenen Domäne sehen. Alle Verzeichnisse/Dateien in/var/www/vhosts/sind Eigentum der jeweiligen Benutzer (Domänenbesitzer), und Sie können sehen, dass sich alle in der Gruppe psacln befinden. Die Lösung bestand also darin, Nginx zu dieser Gruppe hinzuzufügen, damit er sehen kann, was er braucht:

usermod -aG psacln nginx

Starten Sie nginx neu und laden Sie die Seite mit Strg + F5 erneut. 

0

Ich habe eine Problemumgehung gefunden: Der Ordner wurde in den Nginx-Konfigurationsordner verschoben. In meinem Fall "/etc/nginx/my-web-app"." und dann die Berechtigungen für den Root-Benutzer "Sudo chown -R root" geändert : root "my-web-app".

0
Dheeraj