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