web-dev-qa-db-fra.com

Nginx 403 interdit pour tous les fichiers

Nginx est installé avec PHP-FPM sur une unité CentOS 5, mais je ne parviens pas à le faire servir aucun de mes fichiers - que ce soit PHP ou non.

Nginx s'exécute en tant que www-data: www-data et le site par défaut "Bienvenue sur nginx sur EPEL" (appartenant à root: root avec les autorisations 644) se charge très bien.

Le fichier de configuration nginx a une directive include pour /etc/nginx/sites-enabled/*.conf, et j'ai un fichier de configuration example.com.conf , ainsi:

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

Bien que public_html soit la propriété de www-data: www-data avec 2777 autorisations de fichiers, ce site ne parvient pas à diffuser du contenu -

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

J'ai trouvé de nombreux autres messages avec des utilisateurs obtenant 403s de nginx, mais la plupart de ceux que j'ai vus impliquent soit des configurations plus complexes avec Ruby/Passenger (ce que j'ai réussi dans le passé), -FPM est impliqué, donc ils semblent être d'une aide minime.

Ai-je fait quelque chose de stupide ici?

nginxcentoshttp-status-code-403php
167
Angus Ireland

Une exigence d'autorisation souvent négligée est qu'un utilisateur a besoin de x autorisations dans chaque répertoire parent d'un fichier pour accéder à ce fichier. Vérifiez les autorisations sur /,/home,/home/demo, etc. pour un accès www-data x. Mon hypothèse est que/home est probablement 770 et que www-data ne peut pas y accéder pour accéder à un sous-répertoire. Si c'est le cas, essayez avec chmod o + x/home (ou le répertoire qui refuse la demande).

EDIT: pour afficher facilement toutes les autorisations sur un chemin, vous pouvez utiliser namei -om /path/to/check

305
kolbyjack

Si vous voyez toujours permission denied après avoir vérifié les autorisations des dossiers parents, il se peut que SELinux limite l'accès. 

Pour vérifier si SELinux est en cours d'exécution:

# getenforce

Pour désactiver SELinux jusqu'au prochain redémarrage:

# setenforce Permissive

Redémarrez Nginx et voyez si le problème persiste. Pour permettre à nginx de servir votre répertoire www (assurez-vous de réactiver SELinux avant de le tester. I.e, setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Voir mon répondre ici pour plus de détails

263
Kurt

J'ai résolu ce problème en ajoutant des paramètres utilisateur.

dans nginx.conf

worker_processes 4;
user username;

changez le 'nom d'utilisateur' avec le nom d'utilisateur linux.

47
Anderson

J'ai cette erreur et je l'ai finalement résolue avec la commande ci-dessous.

restorecon -r /var/www/html

Le problème est causé lorsque vous déplacez quelque chose d'un endroit à un autre. Il conserve le contexte selinux de l'original lorsque vous le déplacez. Par conséquent, si vous décompressez quelque chose dans/home ou/tmp, il reçoit un contexte selinux qui correspond à son emplacement. Maintenant, vous devez le transférer dans/var/www/html et il prend le contexte indiquant qu'il appartient à/tmp ou à/home avec lui et que httpd n'est pas autorisé par la politique à accéder à ces fichiers. 

Si vous copiez les fichiers au lieu de les mv, le contexte selinux est attribué en fonction de l'emplacement où vous copiez, et non de son origine. L'exécution de restorecon rétablit le contexte par défaut et le corrige également.

26
jsina

J'ai essayé différents cas et uniquement lorsque propriétaire était défini sur nginx (chown -R nginx:nginx "/var/www/myfolder") - il a commencé à fonctionner comme prévu.

21
Andron

Vieille question, mais j'avais le même problème. J'ai essayé chaque réponse ci-dessus, rien n'a fonctionné. Ce qui a résolu le problème pour moi, c’est de supprimer le domaine et de l’ajouter à nouveau. J'utilise Plesk et j'ai installé Nginx APRÈS que le domaine y soit déjà. 

Une sauvegarde locale vers/var/www/backups a tout d'abord été effectuée. Donc, je pourrais facilement copier les fichiers.

Problème étrange ....

1
David

Je me suis plongé dans une légère variante de ce problème en exécutant par erreur la commande setfacl. Iran:

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

J'ai abandonné cette route au profit de l'ajout de nginx au groupe foo, mais cette ACL personnalisée déjouait les tentatives de nginx d'accéder au fichier. Je l'ai effacé en exécutant:

Sudo setfacl -b /home/foo/bar

Et ensuite, nginx a pu accéder aux fichiers.

0
danvk

Nous avons eu le même problème, en utilisant Plesk Onyx 17. Au lieu de gâcher les droits, etc., la solution a été d’ajouter un utilisateur nginx au groupe psacln, dans lequel tous les autres propriétaires de domaine (utilisateurs) étaient:

usermod -aG psacln nginx

Maintenant, nginx a le droit d'accéder à .htaccess ou à tout autre fichier nécessaire pour afficher correctement le contenu. 

D'autre part, assurez-vous également qu'Apache est dans le groupe psaserv afin de servir du contenu statique:

usermod -aG psaserv Apache

Et n'oubliez pas de redémarrer Apache et Nginx dans Plesk après! (et rechargez des pages avec Ctrl-F5)

0
Slavomir Miskovec

Si vous utilisez SELinux, tapez simplement:

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

Cela corrigera le problème de permission.

0
David Ding

Si vous utilisez PHP, assurez-vous que la directive index NGINX du bloc serveur contient un index.php:

index index.php index.html;

Pour plus d'informations, consultez la directive index dans la documentation officielle.

0
Francisco Zanatta