Nginx 403 proibido para todos os arquivos

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?

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

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

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.

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.

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.

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.

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 ....

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)

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.

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.

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.