web-dev-qa-db-fra.com

Nginx: stat () a échoué (13: autorisation refusée)

J'utilise la configuration par défaut lors de l'ajout du répertoire spécifique avec nginx installé sur ma machine Ubuntu 12.04. 

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

...
}

Je veux juste qu'un simple serveur statique nginx serve les fichiers en dehors de ce répertoire. Cependant, en vérifiant le error.log je vois

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

J'ai déjà fait chown -R www-data:www-data sur /username/test/static, je les ai définis sur chmod 755. Je ne sais pas quoi d'autre doit être défini.

ubuntunginx
80
user299709

Nginx fonctionne dans le répertoire. Par conséquent, si vous ne pouvez pas cd dans ce répertoire à partir de l'utilisateur nginx, cela échouera (comme le fait la commande stat dans votre journal). Assurez-vous que le www-user peut cd jusqu'au /username/test/static. Vous pouvez confirmer que la variable stat échouera ou réussira en exécutant

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

Dans votre cas, le répertoire /username est probablement le problème ici. En règle générale, www-data ne dispose pas des autorisations pour cd aux répertoires de base des autres utilisateurs.

La meilleure solution dans ce cas serait d’ajouter www-data au groupe username:

gpasswd -a www-data username

et assurez-vous que le groupe username peut entrer tous les répertoires le long du chemin:

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

Pour que vos modifications fonctionnent, redémarrez nginx

nginx -s reload
148
Maciej Sz

Je viens d'avoir le même problème sur une boîte CentOS 7. 

On dirait que je frappe Selinux. Mettre selinux en mode permissif (setenforce permissive) a permis de résoudre le problème pour le moment. Je vais essayer de revenir avec une solution appropriée.

66
Andrew Richard Miller

Sur CentOS 7.0, ce problème Access Deined était causé par SELinux et les étapes suivantes ont résolu le problème:

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

Mise à jour: Juste une note de côté tirée de ce que j'ai appris en utilisant les serveurs Linux virtuels de digitalocean ou qu'ils appellent Droplets. L'utilisation de SELinux nécessite une quantité de mémoire vive décente. C'est probablement que vous ne pourrez pas exécuter et gérer SELinux sur une gouttelette avec moins de 2 Go de RAM.

30
Achilles

Nginx doit avoir un accès + x sur tous les répertoires menant au répertoire racine du site. 

Assurez-vous d'avoir + x sur tous les répertoires du chemin d'accès à la racine du site. Par exemple, si la racine du site est/home/nom d'utilisateur/siteroot:

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

Il se peut que Security-Enhanced Linux soit en cours d’exécution, alors ajoutez une règle pour cela .

chcon -Rt httpd_sys_content_t /username/test/static

16
Artjom Kurapov

Symptôme: 

Impossible de télécharger des images vers la médiathèque WordPress.

Cause:

(CentOS) yum update

Erreur:

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"

Solution:

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

3
PJ Brunet

Par défaut, les données statiques, lorsque vous installez nginx, seront dans/var/www/html. Vous pouvez donc simplement copier votre dossier statique dans/var/html/et définir le 

root /var/www/<your static folder>

dans ngix.conf (ou/etc/nginx/sites-available/default)

Cela a fonctionné pour moi sur Ubuntu, mais je suppose que cela ne devrait pas être très différent pour les autres distributions. 

J'espère que ça aide. 

2
Patrik Bego

Dans mon cas, le dossier qui servait les fichiers était un lien symbolique vers un autre dossier, créé avec

ln -sf /Origin /var/www/destination

Même si les autorisations (utilisateur et groupe) étaient correctes sur le dossier de destination (le lien symbolique), j'avais toujours l'erreur car Nginx devait également disposer d'autorisations sur la hiérarchie du dossier d'origine.

1
Santiago Martí Olbrich

Changez votre propriété nginx.confuser en www-static fichiers owener.

#   * 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

J'ai fait face à ce problème, je l'ai résolu pour donner des autorisations à l'utilisateur et au groupe nginx quelque chose comme ceci:

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

J'ai eu le même problème, j'utilise Plesk Onyx 17 avec Centos7. Je pouvais voir cette erreur dans proxy_error_log sous les journaux du domaine affecté. Tous les répertoires/fichiers de/var/www/vhosts/sont la propriété d'utilisateurs respectifs (propriétaires de domaine) et vous pouvez voir qu'ils sont tous dans le groupe psacln. La solution a donc été d’ajouter nginx à ce groupe, afin qu’il puisse voir ce dont il a besoin:

usermod -aG psacln nginx

Et en effet, redémarrez nginx et rechargez la page avec Ctrl + F5. 

0
Slavomir Miskovec

J'ai trouvé un moyen de contourner le problème suivant: J'ai déplacé le dossier dans le dossier de configuration nginx, dans mon cas, "/etc/nginx/my-web-app".And. Puis modifié les autorisations d'accès à l'utilisateur root" Sudo chown -R root : root "mon-web-app".

0
Dheeraj