Permission refusée lors de la lecture en amont

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

Vous pouvez découvrir sous quel utilisateur tournent les processus nginx

ps aux | grep "nginx: worker process"

Puis vérifier si les permissions dans vos fichiers de proxy sont correctes

ls -l /opt/nginx/proxy_temp/

Dans mon cas, nginx tournait en tant que www-data et deux des répertoires dans mon répertoire de proxy appartenaient à root.

Je ne sais pas comment cela s'est produit, mais je l'ai résolu en faisant (en tant que root)

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

Vous avez probablement démarré avec l'utilisateur root, puis l'avez changé. Maintenant, le problème est que les dossiers de cache, c'est-à-dire

/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 (www-data ou tout autre que vous essayez de passer à) ne peut pas y accéder car ils ont une permission de 700.

La solution est donc simple. Arrêtez nginx, puis:

rm -rf /var/cache/nginx/*

ou où que le chemin soit sur votre distribution et version. Puis redémarrez nginx, qui recréera ces dossiers avec les permissions appropriées.

Aussi, vérifiez le fichier nginx.conf pour vous assurer que vous spécifiez le bon utilisateur ET groupe.

J'ai eu un problème où les autorisations sur le répertoire étaient configurées pour utilisateur/nginx, mais l'utilisateur nginx.conf spécifiait uniquement le nom d'utilisateur. Par défaut, si aucun groupe n'est donné à la directive utilisateur, il utilise le même nom que l'utilisateur. Donc, nom_utilisateur/nom_utilisateur essayait d'accéder à un répertoire au lieu de utilisateur/nginx. Mettre à jour la configuration a résolu mes problèmes.

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

Alors j'ai fait tout ce qui précède et malheureusement pour moi, ça me donnait la même erreur. Je fais tourner une application Rails empaqueté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 fonctionner en mode enforcing. J'ai simplement changé Nginx en mode permissif avec

setenforce 0

Avec cela, l'erreur a disparu et j'ai pu faire tourner mon application en environnement de staging/production.

J'étais perdu jusqu'à ce que je trouve l'erreur dans le journal d'audit

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 économisera à quelqu'un les 3 heures que je viens de perdre.

Lors du démarrage de nginx à partir d'un compte non privilégié, le use_temp_path=off.

proxy_cache_path ... use_temp_path=off;

Cela est nécessaire pour éviter que nginx essaie de placer les fichiers dans le proxy_temp_path par défaut. Selon la documentation de nginx:

Le répertoire pour les 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 donné sera utilisé. Si la valeur est définie sur off, les fichiers temporaires seront directement placés dans le répertoire de cache.