Permissão negada durante a leitura no upstream

35

Nós implantamos nosso aplicativo rails em nginx e passageiro. Intermitentemente, as páginas do aplicativo são carregadas parcialmente. Não há erro no log do aplicativo. Mas o log de erros 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"

    
por user68613 14.02.2011 / 06:58

6 respostas

34

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, em seguida, verifique se as permissões em seus arquivos de proxy estão corretas

ls -l /opt/nginx/proxy_temp/

No meu caso, o nginx estava rodando como www-data e dois dos diretórios no meu diretório proxy pertenciam ao root.

Eu não sei como isso aconteceu ainda, mas consertei fazendo (como root)

chown www-data.www-data /opt/nginx/proxy_temp
    
por 23.08.2012 / 15:09
8

Verifique também o arquivo nginx.conf para ter certeza de que você está especificando o grupo AND e o usuário corretos.

Eu tive um problema em que as permissões no diretório estavam configuradas para 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 à diretiva do usuário, ele usará o mesmo nome do usuário. Então, nome de usuário / nome de usuário estava tentando acessar um diretório em vez de username / nginx. A atualização da configuração corrigiu meus problemas.

Veja: link

    
por 11.01.2013 / 18:25
7

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, então seu usuário nginx (ou o que você está tentando mudar) não pode acessá-los, pois eles têm uma permissão de 700.

Então a solução é fácil. Pare o nginx, então:

rm -rf /var/cache/nginx/*

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

    
por 17.04.2015 / 20:01
3

Então eu fiz todos os itens 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. Lutei por cerca de 3 horas até encontrar outra solução e espero que ajude outra pessoa. De acordo com este artigo nginx pode ser executado no modo de execução. Eu simplesmente mudei o nginx para o modo permissivo com

setenforce 0

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

Eu estava 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 poupe as 3 horas que eu perdi.

    
por 10.10.2015 / 07:29
3

Ao iniciar o nginx de uma conta sem privilégios, o use_temp_path=off .

proxy_cache_path ... use_temp_path=off;

Isso precisava evitar que o nginx tentasse colocar os arquivos no padrão proxy_temp_path . Da documentação do nginx:

The directory for temporary files is set based on the use_temp_path parameter (1.7.10). If this parameter is omitted or set to the value on, the directory set by the proxy_temp_path directive for the given location will be used. If the value is set to off, temporary files will be put directly in the cache directory.

    
por 02.11.2015 / 17:37
-3
chmod 777 /opt/nginx/proxy_temp/

Eu tive o mesmo problema e resolvi por chmod para esse diretório.

    
por 29.01.2012 / 07:31