Nginx 403 proibido para todos os arquivos

192

Eu tenho o nginx instalado com o PHP-FPM em uma caixa do CentOS 5, mas estou lutando para que ele sirva qualquer um dos meus arquivos - PHP ou não.

O Nginx está sendo executado como www-data: www-data e o site padrão "Bem-vindo ao nginx no EPEL" (de propriedade root: root com 644 permissões) carrega bem.

O arquivo de configuração nginx possui uma diretiva de inclusão para /etc/nginx/sites-enabled/*.conf, e eu tenho um arquivo de configuração example.com.conf , assim:

server {
 listen 80;

 Virtual Host Name
 server_name www.example.com example.com;


 location / {
   root /home/demo/sites/example.com/public_html;
   index index.php index.htm index.html;
 }

 location ~ \.php$ {
  fastcgi_pass   127.0.0.1:9000;
  fastcgi_index  index.php;
  fastcgi_param  PATH_INFO $fastcgi_script_name;
  fastcgi_param  SCRIPT_FILENAME  /home/demo/sites/example.com/public_html$fastcgi_script_name;
  include        fastcgi_params;
 }
}

Apesar de public_html pertencer a www-data: www-data com permissões de arquivo 2777, este site falha ao veicular qualquer conteúdo -

 [error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"

Eu encontrei várias outras postagens com usuários recebendo 403s do nginx, mas a maioria das que eu vi envolvem configurações mais complexas com Ruby / Passenger (com as quais no passado realmente consegui) ou só estão recebendo erros quando o PHP upstream -FPM está envolvido, então eles parecem ser de pouca ajuda.

Eu fiz algo bobo aqui?

Angus Ireland
fonte
verifique esta resposta stackoverflow.com/questions/16808813/…
sandes

Respostas:

333

Um requisito de permissão que geralmente é esquecido é que um usuário precisa de x permissões em todos os diretórios pai de um arquivo para acessar esse arquivo. Verifique as permissões em /, / home, / home / demo, etc. para acessar www-data x access. Meu palpite é que / home provavelmente é 770 e o www-data não pode chdir através dele para chegar a qualquer subdiretório. Se for, tente chmod o + x / home (ou qualquer diretório que esteja negando a solicitação).

EDIT: Para exibir facilmente todas as permissões em um caminho, você pode usar namei -om /path/to/check

kolbyjack
fonte
6
O mesmo aqui. Na minha instalação do CentOS 6, / home / user dirs são definidos como 700 por padrão.
Jjt
2
Esse cara fala sobre isso também: ( chmod -4 +x /mypathtrabalharam para mim) nginxlibrary.com/403-forbidden-error
Peter Ehrlich
1
Alguém pode explicar por que esse comportamento é diferente do apache, que NÃO exige que todo diretório pai tenha permissões "x"?!?
JoshuaDavid
3
Não é diferente. O único motivo pelo qual o apache também não exigiria permissão x nos diretórios-pai é se estiver sendo executado como root.
Kolbyjack
Acabei adicionando o usuário www-data ao meu grupo de usuários pessoais e executando um chmod 710 na minha pasta de usuário raiz. Funcionou como um encanto. (Em uma distribuição baseada em debian)
basicdays 10/07/14
299

Se você ainda vir permission denieddepois de verificar as permissões das pastas pai, talvez o SELinux esteja restringindo o acesso.

Para verificar se o SELinux está em execução:

# getenforce

Para desativar o SELinux até a próxima reinicialização:

# setenforce Permissive

Reinicie o Nginx e verifique se o problema persiste. Para permitir nginx para servir o seu diretório www (certifique-se de transformar o SELinux de volta antes de testar esta. Ie, setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Veja minha resposta aqui para mais detalhes

Kurt
fonte
1
Não conseguia entender por que, sempre que iniciei o nginx, ele dizia open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied)depois de verificar as permissões e ter certeza de que estava sendo iniciado como root. Me deparei com isso e descobri que o SELinux estava ativado. Desativei e agora não funciona. Obrigado!
ub3rst4r
1
Obrigado! Eu ainda tinha um problema com a permissão negada para usuários que possuem as suas próprias bases de FPM para que eu era capaz de corrigir aquele mudando a userpartir nginx a raiz em /var/nginx/nginx.conf- talvez que vai ajudar alguém que se depara com esta questão. S / O para DataPsyche para a segunda parte.
Inverno
11
Esse é o comportamento padrão do CentOS 7 também.
timss 14/02
4
Estou com todo mundo que comentou. Eu estava pronto para jogar meu computador pela janela. O Nginx foi configurado corretamente, as permissões foram definidas corretamente, eu fui até o ponto de fazer tudo 777 e ainda recebi o erro de permissões negadas.
DOfficial
2
No Centos 7 (ativado pelo SELinux), a correção mais simples para mim foi setsebool httpd_read_user_content on(para arquivos estáticos hospedados em um diretório inicial, com chmod'ed para legível pelo mundo) - Embora eu ache que o método do @ KapiteinWitbaard acima é mais seguro.
precisa saber é o seguinte
61

Resolvi esse problema adicionando configurações do usuário.

no nginx.conf

worker_processes 4;
user username;

mude o 'username' com o nome de usuário linux.

Anderson
fonte
4
Acredito que esta resposta seja mais segura em termos de segurança do que a resposta aceita. Você não precisa mexer nas permissões da sua pasta pessoal (que pode conter informações sigilosas) e, se estiver desenvolvendo o nginx, isso evita que você precise enviar permissões de arquivo estranhas ao SCM.
CamelBlues
As permissões adicionadas no diretório inicial são executadas, não lidas, portanto, nenhuma informação confidencial é (em teoria) revelada (exceto, nesse caso, talvez para um script PHP malicioso que se repete para cima e sabe a localização dos arquivos confidenciais em outro diretório acessível a www-data). Você também notará que na pergunta original, meu nginx estava sendo executado como "www-data" - os valores de configuração aqui já estavam definidos como desejado.
Angus Ireland
2
Também tinha que adicionar grupo de usuários: grupo de usuários do usuário.
Gabriel A. Zorrilla
Funcionou para mim também (assim como chmodding o diretório para nginx: nginx). No entanto, prefiro esta solução para que minha raiz do documento seja de propriedade de outro usuário que não o nginx. Obrigado Anderson por apontar isso.
Kvvv 8/07
salvou o meu dia. a propósito, e se a máquina tiver vários usuários e cada usuário tiver seu próprio site, como posso lidar com isso?
psychok7
38

Eu tenho esse erro e finalmente o resolvi com o comando abaixo.

restorecon -r /var/www/html

O problema é causado quando você move algo de um lugar para outro. Ele preserva o contexto selinux do original quando você o move, portanto, se você desarmar algo em / home ou / tmp, ele recebe um contexto selinux que corresponde à sua localização. Agora, você deve fazer isso para / var / www / html e usar o contexto dizendo que pertence a / tmp ou / home com ele, e o httpd não tem permissão pela política para acessar esses arquivos.

Se você copiar os arquivos em vez de movê-los, o contexto do selinux será atribuído de acordo com o local para o qual você está copiando, não de onde vem. A execução de restorecon coloca o contexto de volta ao padrão e o corrige também.

jsina
fonte
1
Graças @jsina, isso me ajudou muito
Pankaj Garg
1
Droga, +1 , eu também.
JWW
24

Eu tentei casos diferentes e somente quando o proprietário foi definido como nginx ( chown -R nginx:nginx "/var/www/myfolder") - ele começou a funcionar conforme o esperado.

Andron
fonte
1
Trabalhou para mim também. Suspeito que isso aconteça porque, embora o nginx seja iniciado como raiz, ele gera processos no usuário especificado no arquivo nginx.conf, que é "user nginx;" por padrão. Alterar o usuário para o proprietário da raiz do documento também deve funcionar como Anderson sugeriu.
kvdv
Sr. Anderson? Não! Andron;)
Andron
Desculpas, Sr. Andron;) Não consigo editar mais o comentário anterior ...
kvdv 14/07/2015
Claro, não é um problema. Agora eu era como Anderson :) e necessidade de escrever alguns contos de fadas ...
Andron
1
Isso não é um problema de segurança?
Gontard 02/12/16
6

Se você estiver usando o SELinux, digite:

sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/

Isso corrigirá o problema de permissão.

David Ding
fonte
1

Pergunta antiga, mas tive o mesmo problema. Eu tentei todas as respostas acima, nada funcionou. O que o corrigiu foi remover o domínio e adicioná-lo novamente. Estou usando o Plesk e instalei o Nginx APÓS o domínio já estar lá.

Embora tenha feito um backup local para / var / www / backups primeiro. Para que eu pudesse copiar facilmente os arquivos novamente.

Problema estranho ....

David
fonte
1

Tivemos o mesmo problema, usando o Plesk Onyx 17. Em vez de mexer nos direitos, etc., a solução foi adicionar o usuário nginx ao grupo psacln, no qual todos os outros proprietários de domínio (usuários) eram:

usermod -aG psacln nginx

Agora, o nginx tem direitos para acessar .htaccess ou qualquer outro arquivo necessário para mostrar corretamente o conteúdo.

Por outro lado, verifique também se o Apache está no grupo psaserv, para veicular conteúdo estático:

usermod -aG psaserv apache

E não se esqueça de reiniciar o Apache e o Nginx no Plesk depois! (e recarregue as páginas com Ctrl-F5)

Slavomir Miskovec
fonte
Essa é a resposta correta e é mais provável usermod -aG username www-datana maioria das configurações.
Dario Zadro
0

Eu me envolvi em uma ligeira variante desse problema executando o setfaclcomando por engano . Eu corri:

sudo setfacl -m user:nginx:r /home/foo/bar

Abandonei esta rota em favor da adição nginx no foogrupo, mas essa ACL personalizada estava frustrando as tentativas do nginx de acessar o arquivo. Eu limpei executando:

sudo setfacl -b /home/foo/bar

E então o nginx conseguiu acessar os arquivos.

danvk
fonte
0

Se você estiver usando PHP, verifique se a indexdiretiva NGINX no bloco do servidor contém um index.php:

index index.php index.html;

Para mais informações, consulte a diretiva de índice na documentação oficial.

Francisco Zanatta
fonte
0

Eu estava enfrentando o mesmo problema, mas as soluções acima não ajudaram.

Então, depois de muita luta, descobri que o sestatus estava definido para impor quais blocos todas as portas e ao permitir que todos os problemas fossem resolvidos.

sudo setenforce 0

Espero que isso ajude alguém como eu.

Harvey
fonte
Embora isso possa ter resolvido o seu problema - parabéns! - isso é um pouco triste :-( Veja stopdisablingselinux.com - você pode encontrar uma solução diferente?
Angus Ireland