В доступе отказано при чтении вверх по течению

Мы развернули наше приложение rails на nginx и passenger. Периодически страницы приложения загружаются частично. В журнале приложений нет ошибок. Но журнал ошибок nginx показывает следующее:

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"

У меня была такая же проблема при настройке NGINX / PHP-FPM (php-fpm = улучшенные fcgi для php).

Вы можете узнать, от какого пользователя запущены процессы nginx

ps aux | grep "nginx: worker process"

А затем проверьте правильность разрешений в ваших прокси-файлах.

ls -l /opt/nginx/proxy_temp/

В моем случае nginx работал как www-dataи два из каталогов в моем прокси-каталоге принадлежали root.

Я пока не знаю, как это произошло, но я исправил это, выполнив (как root)

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

Вы, вероятно, начали с пользователя root, а затем изменили его. Теперь проблема в том, что кеш папок, т.е.

/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

уже принадлежат пользователю root, поэтому ваш пользователь nginx (или любой другой пользователь, к которому вы пытаетесь переключиться) не может получить к ним доступ, поскольку у него есть разрешение 700.

Так что решение легко. Остановите nginx, затем:

rm -rf /var/cache/nginx/*

или какой-либо путь в вашем дистрибутиве и релиз. Затем перезапустите nginx, который заново создаст эти папки с соответствующими разрешениями.

Также проверьте файл nginx.conf, чтобы убедиться, что вы указываете правильную группу AND AND.

У меня была проблема, когда права доступа к каталогу были настроены для имени пользователя / nginx, но пользователь nginx.conf указывал только имя пользователя. По умолчанию, если в пользовательской директиве нет группы, она использует то же имя, что и пользователь. Итак, имя пользователя / имя пользователя пыталось получить доступ к каталогу вместо имени пользователя / nginx. Обновление конфига исправило мои проблемы.

Смотрите: http://nginx.org/en/docs/ngx_core_module.html#user

Так что я сделал все вышеперечисленное, и, к сожалению, для меня это дало мне ту же ошибку. Я запускаю приложение rails, упакованное в jar-файл с крутящим моментом на машине Centos 6.7 с nginx. Я боролся с этим около 3 часов, пока не нашел другое решение, и я надеюсь, что это поможет кому-то еще. Согласно этой статье nginx может работать в принудительном режиме. Я просто изменил nginx в разрешающий режим с

setenforce 0

После этого ошибка исчезла, и я смог запустить свое приложение в рабочей среде.

Я был невежественен, пока не нашел ошибку в 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

Я действительно надеюсь, что это спасет кого-то 3 часа, которые я только что потерял.

При запуске nginx из непривилегированного аккаунта use_temp_path=off.

proxy_cache_path ... use_temp_path=off;

Это необходимо для того, чтобы nginx не пытался поместить файлы в настройки по умолчанию proxy_temp_path. Из документации nginx:

Каталог для временных файлов устанавливается на основе параметра use_temp_path (1.7.10). Если этот параметр пропущен или для него задано значение, будет использоваться каталог, заданный директивой proxy_temp_path для данного местоположения. Если значение отключено, временные файлы будут помещены непосредственно в каталог кеша.

chmod 777 /opt/nginx/proxy_temp/

У меня была та же проблема, и она была решена с помощью chmod в этот каталог.