Nginx 403 interdit pour tous les fichiers


192

J'ai installé nginx avec PHP-FPM sur une boîte CentOS 5, mais j'ai du mal à le faire servir l'un 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 "Welcome to nginx on EPEL" (appartenant à root: root avec 644 permissions) se charge correctement.

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

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 appartienne à www-data: www-data avec 2777 autorisations de fichier, ce site ne parvient à diffuser aucun 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 articles avec des utilisateurs obtenant des 403 de nginx, mais la plupart que j'ai vus impliquent des configurations plus complexes avec Ruby / Passenger (avec lesquelles j'ai réussi dans le passé) ou ne reçoivent des erreurs que lorsque PHP en amont -FPM est impliqué, donc ils semblent être de peu d'aide.

Ai-je fait quelque chose de stupide ici?


Réponses:


334

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

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


6
Pareil ici. Sur mon installation de CentOS 6, les répertoires / home / user sont définis sur 700 par défaut.
jjt

2
Ce gars en parle aussi: (a chmod -4 +x /mypathtravaillé pour moi) nginxlibrary.com/403-forbidden-error
Peter Ehrlich

1
Quelqu'un peut-il expliquer pourquoi ce comportement est différent d'Apache qui n'exige PAS que chaque répertoire parent ait les autorisations "x"?!?
JoshuaDavid

3
Ce n'est pas différent. La seule raison pour laquelle Apache n'a pas également besoin de l'autorisation x sur les répertoires parents est s'il s'exécute en tant que root.
kolbyjack

J'ai fini par ajouter l'utilisateur www-data à mon groupe d'utilisateurs personnel et faire un chmod 710 dans mon dossier d'utilisateur racine. A travaillé comme un charme. (Sur une distribution basée sur Debian)
Basicdays

299

Si vous voyez toujours permission deniedaprès avoir vérifié les autorisations des dossiers parents, il se peut que SELinux restreigne 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 tester cela. C.-à-d. setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Voir ma réponse ici pour plus de détails


1
Je ne pouvais pas comprendre pourquoi chaque fois que je démarrais nginx, cela disait open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied)après avoir vérifié les autorisations et m'être assuré qu'il était démarré en tant que root. Je suis tombé sur cela et j'ai découvert que SELinux était activé. Je l'ai désactivé et maintenant cela fonctionne sans problème. Merci!
ub3rst4r

1
Merci! J'ai toujours eu un problème avec l'autorisation refusée pour les utilisateurs possédant leurs propres sockets FPM, j'ai donc pu résoudre celui-ci en changeant userde nginx en root in /var/nginx/nginx.conf- peut-être que cela aidera quelqu'un d'autre qui rencontrera ce problème. S / O à DataPsyche pour la deuxième partie.
Hiver

11
Il s'agit également du comportement par défaut sur CentOS 7.
timss

4
Je suis avec tout le monde qui a commenté. J'étais prêt à jeter mon ordinateur par la fenêtre. Nginx a été configuré correctement, les autorisations étaient correctement définies, je suis même allé aussi loin pour tout faire 777 et j'ai toujours obtenu des autorisations refusées.
Officiel

2
Sur Centos 7 (SELinux activé), le correctif le plus simple pour moi était setsebool httpd_read_user_content on(Pour les fichiers statiques hébergés à partir d'un répertoire personnel, chmod'ed en lecture universelle) - Bien que je suppose que la méthode de @ KapiteinWitbaard ci-dessus est plus sécurisée.
TimStaley

63

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.


4
Je pense que cette réponse est plus sécuritaire que la réponse acceptée. Vous n'avez pas à vous soucier des autorisations sur votre dossier de départ (qui pourrait contenir des informations sensibles) et si vous faites du développement avec nginx, cela vous évite d'avoir à télécharger des autorisations de fichiers étranges sur SCM.
CamelBlues

Les autorisations ajoutées sur le répertoire de base sont exécutées, pas lues, donc aucune information sensible n'est (en théorie) révélée (sauf, dans ce cas, peut-être à un script PHP malveillant qui se répète vers le haut et connaît l'emplacement des fichiers sensibles dans un autre répertoire accessible à www-data). Vous remarquerez également que dans la question d'origine, mon nginx fonctionnait en tant que "www-data" - les valeurs de configuration ici étaient déjà définies comme vous le souhaitez.
Angus Ireland

2
J'ai dû également ajouter un groupe d'utilisateurs: user usegroup.
Gabriel A. Zorrilla

A fonctionné pour moi aussi (tout comme chmodding le dir en nginx: nginx). Je préfère cette solution pour que la racine de mon document soit la propriété d'un autre utilisateur que nginx. Merci Anderson pour l'avoir signalé.
kvdv

m'a sauvé la journée. Au fait, que se passe-t-il si la machine a plusieurs utilisateurs et que chaque utilisateur a son propre site Web, comment puis-je y faire face?
psychok7

38

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 passez quelque chose d'un endroit à un autre. Il préserve le contexte selinux de l'original lorsque vous le déplacez, donc si vous décompressez quelque chose dans / home ou / tmp, il obtient un contexte selinux qui correspond à son emplacement. Maintenant, vous envoyez cela à / var / www / html et il prend le contexte disant qu'il appartient à / tmp ou / home avec lui et httpd n'est pas autorisé par la politique à accéder à ces fichiers.

Si vous cp les fichiers au lieu de les mv, le contexte selinux est attribué en fonction de l'emplacement vers lequel vous copiez, pas d'où il vient. L'exécution de restorecon remet le contexte à sa valeur par défaut et le corrige également.


1
Merci @jsina, cela m'a beaucoup aidé
Pankaj Garg

1
Merde, +1 , moi aussi.
jww

24

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


1
A travaillé pour moi aussi. Je soupçonne que cela se produit parce que même si nginx est démarré en tant que root, il génère des processus sous l'utilisateur spécifié dans le fichier nginx.conf, qui est "user nginx;" par défaut. Changer l'utilisateur pour celui qui possède la racine de votre document devrait également fonctionner comme Anderson l'a suggéré.
kvdv

M. Anderson? Non! Andron;)
Andron

Excuses M. Andron;) Je n'arrive plus à modifier le commentaire précédent cependant ...
kvdv

Bien sûr, pas de problème. Maintenant, j'étais comme Anderson :) et j'ai besoin d'écrire des contes de fées ...
Andron

1
N'est-ce pas un problème de sécurité?
gontard

6

Si vous utilisez SELinux, tapez simplement:

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

Cela résoudra le problème d'autorisation.


1

Ancienne question, mais j'ai eu le même problème. J'ai essayé toutes les réponses 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 était déjà là.

J'ai d'abord fait une sauvegarde locale sur / var / www / backups. Je pourrais donc facilement recopier les fichiers.

Problème étrange ...


1

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

usermod -aG psacln nginx

Désormais, nginx a le droit d'accéder au .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, pour servir du contenu statique:

usermod -aG psaserv apache

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


C'est la bonne réponse et c'est probablement usermod -aG username www-datasur la plupart des configurations.
Dario Zadro

0

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

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

J'ai abandonné cette route en faveur de l'ajout nginxau foogroupe, 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 puis nginx a pu accéder aux fichiers.


0

Si vous utilisez PHP, assurez-vous que la indexdirective NGINX dans le bloc serveur contient un index.php:

index index.php index.html;

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


0

J'étais confronté au même problème, mais les solutions ci-dessus n'ont pas aidé.

Ainsi, après beaucoup de lutte, j'ai découvert que sestatus était configuré pour appliquer ce qui bloque tous les ports et en le paramétrant sur permissif, tous les problèmes ont été résolus.

sudo setenforce 0

J'espère que cela aide quelqu'un comme moi.


Bien que cela ait pu résoudre votre problème - félicitations! - c'est un peu triste :-( Voir stopdisablingselinux.com - pourriez-vous trouver une solution de contournement différente?
Angus Ireland
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.