Autorisation refusée lors de la lecture en amont


40

Nous avons déployé notre application rails sur nginx et passagers.Par ailleurs, les pages de l'application sont partiellement chargées. Il n'y a pas d'erreur dans le journal des applications.

2011/02/14 05:49:34 [crit] 25389#0: *645 open() "/opt/nginx/proxy_temp/2/02/0000000022" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: y.y.y.y, request: "GET /signup/procedures?count=0 HTTP/1.1", upstream: "passenger:unix:/passenger_helper_server:", host: "y.y.y.y", referrer: "http://y.y.y.y/signup/procedures"


Vous pouvez définir le niveau de journalisation sur débogage: nginx.org/en/docs/debugging_log.html
Rimian

Réponses:


39

J'ai eu le même problème sur une configuration NGINX / PHP-FPM (php-fpm = fcgi amélioré pour php).

Vous pouvez savoir quel utilisateur les processus nginx s'exécutent en tant que

ps aux | grep "nginx: worker process"

Et puis vérifiez si les autorisations dans vos fichiers proxy sont correctes

ls -l /opt/nginx/proxy_temp/

Dans mon cas, nginx s’exécutait en tant que www-dataet deux des répertoires de mon répertoire proxy appartenaient à root.

Je ne sais pas encore comment c'est arrivé, mais je l'ai corrigé en faisant (en tant que root)

chown www-data.www-data /opt/nginx/proxy_temp

4
La meilleure solution!
Efkan

Pourquoi n'est-il pas encore accepté?
Kishor Pawar

1
pour ceux qui utilisent #openresty - "chown www-data: www-data -R / usr / local / openresty / nginx / * _ temp"
BG Bruno

1
J'ai arrêté mon processus nginx, renommé le dossier sous un autre nom, redémarré le processus nginx et le dossier a été créé à nouveau avec les autorisations appropriées. Travaillé comme un charme!
Chirayu Shishodiya

8

Vous avez probablement commencé avec l'utilisateur root, puis l'avez modifié. Maintenant, le problème est que les dossiers de cache, à savoir

/var/cache/nginx/client_temp
/var/cache/nginx/fastcgi_temp
/var/cache/nginx/proxy_temp
/var/cache/nginx/scgi_temp
/var/cache/nginx/uwsgi_temp

sont déjà possédés par root, donc votre utilisateur nginx (ou ce que vous essayez de basculer vers) ne peut pas y accéder car ils ont une permission de 700.

Donc la solution est facile. Arrêtez nginx, puis:

rm -rf /var/cache/nginx/*

ou quel que soit le chemin est sur votre distribution et libérer. Ensuite, redémarrez nginx qui recréera ces dossiers avec les autorisations appropriées.


8

Vérifiez également le fichier nginx.conf pour vous assurer que vous spécifiez le groupe d'utilisateurs ET approprié.

J'ai eu un problème où les autorisations sur le répertoire ont été configurées pour nom d'utilisateur / nginx, mais l'utilisateur nginx.conf a uniquement spécifié le nom d'utilisateur. Par défaut, si aucun groupe n'est attribué à la directive user, celle-ci utilise le même nom que user. Donc, nom d'utilisateur / nom d'utilisateur essayait d'accéder à un répertoire au lieu de nom d'utilisateur / nginx. La mise à jour de la configuration a corrigé mes problèmes.

Voir: http://nginx.org/en/docs/ngx_core_module.html#user


2
Pouvez-vous s'il vous plaît poster la configuration que vous avez mentionnée ici?
Paweloque

5

J'ai donc fait tout ce qui précède et malheureusement pour moi, cela me donnait la même erreur. Je suis en train d'exécuter une application rails emballée dans un fichier jar avec torquebox sur une machine centos 6.7 avec nginx. J'ai lutté pendant environ 3 heures jusqu'à ce que je trouve une autre solution et j'espère que cela aidera quelqu'un d'autre. Selon cet article, nginx peut s'exécuter en mode d'exécution. Je viens simplement de changer nginx en mode permissif avec

setenforce 0

Avec cela, l'erreur avait disparu et je pouvais exécuter mon application dans un environnement de transfert / de production.

J'étais désemparé jusqu'à ce que j'ai trouvé l'erreur sur le site audit.log

type=AVC msg=audit(1444454198.438:466): avc:  denied  { name_connect } for  pid=3201 comm="nginx" dest=8080 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket

J'espère vraiment que cela sauvera les 3 heures que je viens de perdre.


1
Vous ne vous trompez pas, je ne sais pas pourquoi quelqu'un vote -1 (honte à lui / elle). Le problème concerne les hôtes RedHat / CentOS et selinux. L'une des méthodes possibles est setenforce 0 (grossier), l'autre méthode consiste à définir les options setsebool et réseau.
Periket2000

Cela a aidé avec CentOS 7.2.
MKatleast3

setsebool -P httpd_can_network_connect 1 de stackoverflow.com/a/24830777/721331
McKelvin

3

Lorsque vous démarrez nginx à partir d’un compte non privilégié, le use_temp_path=off.

proxy_cache_path ... use_temp_path=off;

Cela devait éviter que nginx essaye de mettre les fichiers par défaut proxy_temp_path. Dans les documents nginx:

Le répertoire des fichiers temporaires est défini en fonction du paramètre use_temp_path (1.7.10). Si ce paramètre est omis ou défini sur la valeur on, le répertoire défini par la directive proxy_temp_path pour l'emplacement indiqué sera utilisé. Si la valeur est désactivée, les fichiers temporaires seront placés directement dans le répertoire de cache.


-3
chmod 777 /opt/nginx/proxy_temp/

J'ai eu le même problème et il a été résolu par chmod dans ce répertoire.


13
chmod 777 n'est jamais une bonne idée.
sendmoreinfo
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.