Nginx: stat () falhou (13: permissão negada)

Estou usando a configuração padrão ao adicionar o diretório específico com o nginx instalado na minha máquina ubuntu 12.04.

server {
        #listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default ipv6only=on; ## listen for ipv6

        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to index.html
                root /username/test/static;
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }
...

...
}

Eu só quero um servidor nginx estático simples para servir arquivos fora desse diretório. No entanto, verificando o error.logque eu vejo

2014/09/10 16:55:16 [crit] 10808#0: *2 stat() "/username/test/static/index.html" failed (13: Permission denied), client:, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "domain"
2014/09/10 16:55:16 [error] 10808#0: *2 rewrite or internal redirection cycle while internally redirecting to "/index.html

Eu já fiz chown -R www-data:www-dataem /username/test/static, eu configurei-los para chmod 755. Não sei o que mais precisa ser definido.

O Nginx opera dentro do diretório, portanto, se você não cdconseguir statacessar esse diretório do usuário nginx, ele falhará (assim como o comando em seu log). Certifique-se de que a www-userlata vai cdaté o /username/test/static. Você pode confirmar se o statfalhará ou terá sucesso executando

sudo -u www-data stat /username/test/static

No seu caso, provavelmente o /usernamediretório é o problema aqui. Normalmente www-datanão tem permissão para cdacessar os diretórios pessoais de outros usuários.

A melhor solução nesse caso seria adicionar www-dataao usernamegrupo:

gpasswd -a www-data username

e certifique-se de que esse usernamegrupo pode inserir todos os diretórios ao longo do caminho:

chmod g+x /username && chmod g+x /username/test && chmod g+x /username/test/static

Para que suas alterações funcionem, reinicie o nginx

nginx -s reload

Acabo de ter o mesmo problema em uma caixa CentOS 7.

Parece que atingi o selinux. Colocar o selinux no modo permissivo ( setenforce permissive) resolveu o problema por enquanto. Vou tentar voltar com uma correção adequada.

O Nginx precisa ter acesso + x em todos os diretórios que levam ao diretório raiz do site.

Certifique-se de ter + x em todos os diretórios no caminho que conduz à raiz do site. Por exemplo, se a raiz do site for / home / username / siteroot:

chmod +x /home/
chmod +x /home/username
chmod +x /home/username/siteroot

No CentOS 7.0 eu tive esse Access Deinedproblema causado pelo SELinux e estas etapas resolveram o problema:

yum install -y policycoreutils-devel
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp

Atualização: Apenas uma observação do que aprendi ao usar os servidores Linux virtuais da digitalocean, ou como eles chamam de Droplets . Usar o SELinux requer uma quantidade decente de RAM. É mais provável que você não consiga executar e gerenciar o SELinux em um droplet com menos de 2 GB de RAM.

Você pode ter o Security-Enhanced Linux em execução, portanto, adicione uma regra para isso. Tive permissão 13 erros, embora as permissões tenham sido definidas e o usuário existisse.

chcon -Rt httpd_sys_content_t /username/test/static

Sintoma:

Não foi possível fazer upload de imagens para a biblioteca de mídia do WordPress.

Causa:

(CentOS) yum update

Erro:

2014/10/22 18:08:50 [crit] 23286#0: *5332 open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied), client: 1.2.3.4, server: _, request: "POST /wp-admin/media-new.php HTTP/1.1", host: "example.com", referrer: "http://example/wp-admin/media-new.php"

Solução:

chown -R www-data:www-data /var/lib/nginx

Por padrão, os dados estáticos, quando você instala o nginx, estarão em / var / www / html. Portanto, você pode apenas copiar sua pasta estática em / var / html / e definir o

root /var/www/<your static folder>

em ngix.conf (ou / etc / nginx / sites-available / default)

Isso funcionou para mim no Ubuntu, mas acho que não deve ser muito diferente para outras distros.

Espero que ajude.

Mude sua nginx.conf userpropriedade para www-staticarquivos owener.

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user your_user_name;

# same other config

Eu enfrentei esse problema, resolvi para dar permissões ao usuário nginx e agrupar algo assim:

chown -R nginx:nginx /username/test/static

No meu caso, a pasta que servia os arquivos era um link simbólico para outra pasta, feito com

ln -sf /origin /var/www/destination

Mesmo que as permissões (usuário e grupo) estivessem corretas na pasta de destino (o link simbólico), ainda tive o erro porque o Nginx precisava ter permissões para a hierarquia de toda a pasta de origem também.

Eu finalmente encontrei meu caminho. Resumindo, digamos que seu nome de usuário é joee você possui um site em seu sistema de arquivos pessoal /home/joe/path/to/website.

Você literalmente tem que dizer ao sistema que nginxé seu amigo.
Colocar nginxno joegrupo:

sudo gpasswd -a nginx joe

Depois disso, se ainda não funcionar, verifique o acesso correto do /home/joediretório. Essa é provavelmente a razão pela qual o nginx não consegue acessar o arquivo, porque mesmo que ele seja seu amigo agora você tem que abrir a porta de sua casa para ele:

sudo chmod g+x /home/joe

É isso aí. Isso é literalmente tudo que você precisa fazer para dar ao nginx acesso aos seus arquivos locais :)

Não acho que haja preocupações de segurança com esse método porque nginxé a autoridade máxima e apenas um administrador pode alterar o grupo. nginxagora pode ler o que está nos joediretórios. É apenas uma violação de segurança se o titular da nginxconta for diferente do usuário a partir do qual você abre o acesso ao diretório, mas no meu caso sou o titular de ambas as partes, ou seja, em um contexto local.

Eu tive o mesmo problema, estou usando o Plesk Onyx 17 com Centos7. Pude ver esse erro em proxy_error_log nos logs do domínio afetado. Todos os diretórios / arquivos em / var / www / vhosts / são de propriedade dos respectivos usuários (proprietários de domínio) e você pode ver que todos eles estão no grupo psacln. Portanto, a solução foi adicionar o nginx também a este grupo, para que ele possa ver o que precisa:

usermod -aG psacln nginx

E, de fato, reinicie o nginx e recarregue a página com Ctrl + F5.

Eu encontrei uma solução alternativa: Mudei a pasta para a pasta de configuração do nginx, no meu caso "/ etc / nginx / my-web-app". E então alterou as permissões para o usuário root "sudo chown -R root: root" my-web-app ".

Você também pode adicionar qual usuário executará o nginx. No arquivo nginx.conf, faça as seguintes alterações:

user root;

Você pode adicionar a linha acima como a primeira linha em seu nginx conf. Você pode escrever o nome de qualquer usuário que tenha permissão para escrever nesse diretório.

Este é geralmente o problema de privilégios ... Para mim, é porque eu uso o / root / ** como raiz do nginx, ele precisa de privilégios mais elevados. Uma maneira fácil é simplesmente mover o projeto para um diretório criado por você.