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 un simple serveur nginx statique pour servir les fichiers de ce répertoire. Cependant, en vérifiant le error.logje 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

Je l' ai déjà fait chown -R www-data:www-datasur /username/test/static, je les ai mis à chmod 755. Je ne sais pas quoi d'autre doit être réglé.

Nginx fonctionne dans le répertoire, donc si vous ne pouvez pas cdaccéder à ce répertoire à partir de l'utilisateur nginx, il échouera (tout comme la statcommande dans votre journal). Assurez-vous que la www-userboîte de conserve cdjusqu'au /username/test/static. Vous pouvez confirmer que l' statéchouera ou réussira en exécutant

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

Dans votre cas, le /usernamerépertoire est probablement le problème ici. N'a généralement www-datapas d'autorisations sur cdles répertoires personnels des autres utilisateurs.

La meilleure solution dans ce cas serait d'ajouter www-dataau usernamegroupe:

gpasswd -a www-data username

et assurez-vous que ce usernamegroupe 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

J'ai juste eu le même problème sur une box CentOS 7.

Il semble que j'aie touché selinux. Mettre selinux en mode permissif ( setenforce permissive) a résolu le problème pour le moment. Je vais essayer de revenir avec une solution appropriée.

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 dans le chemin menant à la racine du site. Par exemple, si la racine du site est / home / username / siteroot:

chmod +x /home/
chmod +x /home/username
chmod +x /home/username/siteroot

Sur CentOS 7.0, j'ai eu ce Access Deinedproblème causé par SELinux et ces étapes 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é de ce que j'ai appris en utilisant les serveurs Linux virtuels de digitalocean, ou comme ils les appellent Droplets . L'utilisation de SELinux nécessite une quantité décente de RAM. C'est très probablement comme si vous ne pourrez pas exécuter et gérer SELinux sur une goutte avec moins de 2 Go de RAM.

Vous avez peut-être Linux à sécurité renforcée en cours d'exécution, alors ajoutez une règle pour cela. J'ai eu 13 erreurs d'autorisation, même si les autorisations ont été définies et que l'utilisateur existait.

chcon -Rt httpd_sys_content_t /username/test/static

Symptôme:

Impossible de télécharger des images dans 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

Par défaut, les données statiques, lorsque vous installez le 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.

Changez votre nginx.conf userpropriété en www-staticfichiers owener.

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

user your_user_name;

# same other config

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

chown -R nginx:nginx /username/test/static

Dans mon cas, le dossier qui servait les fichiers était un lien symbolique vers un autre dossier, réalisé 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 avoir des autorisations sur la hiérarchie du dossier d'origine.

J'ai finalement trouvé mon chemin. En bref, disons que votre nom d'utilisateur est joeet que vous détenez un site Web sous votre système de fichiers personnel /home/joe/path/to/website.

Vous devez littéralement dire au système qu'il nginxs'agit de votre ami.
Placez nginxen joegroupe:

sudo gpasswd -a nginx joe

Après cela, si cela ne fonctionne toujours pas, vérifiez le droit d'accès au /home/joerépertoire. C'est probablement la raison pour laquelle nginx ne peut pas accéder au fichier car même s'il est votre ami, vous devez maintenant lui ouvrir la porte de votre maison:

sudo chmod g+x /home/joe

C'est tout. C'est littéralement tout ce que vous avez à faire pour donner à nginx l'accès à vos fichiers locaux :)

Je ne pense pas qu'il y ait des problèmes de sécurité avec cette méthode car nginxc'est la haute autorité et seul un administrateur peut changer le groupe. nginxpeut maintenant lire le contenu des joerépertoires. Ce n'est qu'une faille de sécurité si le titulaire du nginxcompte est différent de l'utilisateur à partir duquel vous ouvrez l'accès à l'annuaire, mais dans mon cas, je suis le titulaire des deux parties, c'est-à-dire dans un contexte local.

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 concerné. Tous les répertoires / fichiers dans / var / www / vhosts / sont la propriété des utilisateurs respectifs (propriétaires de domaine) et vous pouvez voir qu'ils sont tous dans le groupe psacln. La solution était donc d'ajouter nginx également à 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.

J'ai trouvé une solution: déplacé le dossier dans le dossier de configuration de nginx, dans mon cas "/ etc / nginx / my-web-app". Et puis changé les permissions de l'utilisateur root "sudo chown -R root: root" my-web-app ".

Vous pouvez également ajouter quel utilisateur exécutera le nginx. Dans le fichier nginx.conf, apportez les modifications suivantes:

user root;

Vous pouvez ajouter la ligne ci-dessus comme première ligne dans votre configuration nginx. Vous pouvez écrire le nom de tout utilisateur autorisé à écrire dans ce répertoire.

C'est généralement le problème des privilèges ... Pour moi, c'est parce que j'utilise le / root / ** comme racine nginx, il a besoin de privilèges plus élevés. Un moyen simple consiste simplement à déplacer le projet dans un répertoire créé par vous-même.