Permissão negada ao ler a montante

Implementamos nosso aplicativo de trilhos no nginx e passenger.Intermitentemente, as páginas do aplicativo são carregadas parcialmente.Não há erro no log do aplicativo.Mas o log de erro do nginx mostra o seguinte:

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"

Eu tive o mesmo problema em uma configuração NGINX / PHP-FPM (php-fpm = fcgi aprimorado para php).

Você pode descobrir qual usuário os processos nginx estão executando como

ps aux | grep "nginx: worker process"

E verifique se as permissões nos seus arquivos proxy estão corretas

ls -l /opt/nginx/proxy_temp/

No meu caso, o nginx estava sendo executado www-datae dois dos diretórios no meu diretório proxy pertenciam ao root.

Ainda não sei como aconteceu, mas consertei fazendo (como root)

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

Você provavelmente começou com o usuário root e o alterou. Agora o problema é que as pastas de cache, ou seja,

/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

já são de propriedade do root, portanto, seu usuário do nginx (ou o que quer que esteja tentando mudar) não pode acessá-lo porque ele tem uma permissão de 700.

Portanto, a solução é fácil. Pare o nginx e, em seguida:

rm -rf /var/cache/nginx/*

ou qualquer que seja o caminho em sua distribuição e liberação. Em seguida, reinicie o nginx, que recriará essas pastas com as permissões apropriadas.

Verifique também o arquivo nginx.conf para verificar se você está especificando o usuário E o grupo correto.

Ocorreu um problema em que as permissões no diretório foram configuradas para o nome de usuário / nginx, mas o usuário nginx.conf especificou apenas o nome de usuário. Por padrão, se nenhum grupo for fornecido para a diretiva de usuário, ele usará o mesmo nome que o usuário. Portanto, nome de usuário / nome de usuário estava tentando acessar um diretório em vez de nome de usuário / nginx. A atualização da configuração corrigiu meus problemas.

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

Então eu fiz todas as opções acima e, infelizmente, para mim, estava me dando o mesmo erro. Estou executando um aplicativo de trilhos empacotado em um arquivo jar com torquebox em uma máquina centos 6.7 com nginx. Eu lutei com isso por cerca de 3 horas até encontrar outra solução e espero que ajude outra pessoa. De acordo com este artigo, o nginx pode ser executado no modo de imposição. Eu simplesmente mudei o nginx para o modo permissivo com

setenforce 0

Com isso, o erro se foi e eu pude executar meu aplicativo em um ambiente de preparação / produção.

Fiquei sem noção até encontrar o erro no 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

Eu realmente espero que isso salve alguém nas 3 horas que acabei de perder.

Ao iniciar o nginx a partir de uma conta não privilegiada, o use_temp_path=off.

proxy_cache_path ... use_temp_path=off;

Isso era necessário para evitar que o nginx tentasse colocar os arquivos no padrão proxy_temp_path. Nos documentos nginx:

O diretório para arquivos temporários é definido com base no parâmetro use_temp_path (1.7.10). Se esse parâmetro for omitido ou definido como o valor ativado, o diretório definido pela diretiva proxy_temp_path para o local especificado será usado. Se o valor estiver desativado, os arquivos temporários serão colocados diretamente no diretório de cache.

chmod 777 /opt/nginx/proxy_temp/

Eu tive o mesmo problema e ele resolveu pelo chmod nesse diretório.