Corrigindo erros de permissão no cache do NGINX ao servir arquivos via FastCGI

Recentemente, enquanto trabalhava em um ambiente baseado em WordPress, percebi que um script responsável por baixar arquivos .po exportados de um projeto de tradução não estava funcionando corretamente. Durante os testes com wget, me deparei com o seguinte erro nos logs do NGINX: open() "/var/cache/nginx/fastcgi_temp/..." failed (13: Permission denied) Esse erro acontece quando o processo do NGINX não consegue acessar os arquivos temporários que o PHP-FPM está tentando enviar como resposta. No meu caso, o FastCGI estava usando o socket do PHP 7.4, e o NGINX não tinha permissão para acessar os arquivos temporários dentro de /var/cache/nginx/fastcgi_temp. Cuidado com permissões Ao listar a estrutura da pasta, percebi que o dono e grupo das subpastas estavam misturados: ls -lha /var/cache/nginx Resultado inicial: drwx------ 12 nginx nginx 4.0K fastcgi_temp Por padrão, o ideal é que: A pasta (fastcgi_temp, proxy_temp, etc.) seja de propriedade nginx:root O conteúdo interno (arquivos e subpastas) fique com nginx:nginx Isso garante que só o processo do NGINX possa escrever e ler dentro dessas pastas, sem comprometer a estrutura principal mantida pelo root. Solução que apliquei Ajustei o dono das subpastas para nginx:root: sudo chown nginx:root /var/cache/nginx/*/ Em seguida, alterei recursivamente o dono dos arquivos dentro dessas pastas para nginx:nginx: sudo find /var/cache/nginx/ -mindepth 2 -exec chown nginx:nginx {} \; Com isso, os arquivos temporários passaram a ser lidos normalmente, e o erro desapareceu. Finalizei com um reload no NGINX: sudo systemctl reload nginx Dica: valide o usuário do processo do NGINX Use: ps -ef | grep nginx No meu caso, o processo estava rodando com o usuário nginx, então as permissões acima estavam corretas. Se o seu estiver rodando como www-data, substitua os comandos conforme necessário. Um pouco da experiência Como trabalho com infraestrutura e automações em ambientes cloud, é comum lidar com detalhes assim que não aparecem em tutoriais ou docs simplificadas. Essa foi mais uma situação onde precisei entender o funcionamento interno do NGINX e PHP-FPM para resolver um problema de permissão sutil, mas crítico para o funcionamento do sistema. Esses pequenos ajustes fazem toda diferença em produção, principalmente quando usamos cache, sockets e servimos arquivos via FastCGI. Se você curte esse tipo de dica e debug, me segue aqui no dev.to ou dá um like no post

Apr 23, 2025 - 17:53

Corrigindo erros de permissão no cache do NGINX ao servir arquivos via FastCGI

Recentemente, enquanto trabalhava em um ambiente baseado em WordPress, percebi que um script responsável por baixar arquivos .po exportados de um projeto de tradução não estava funcionando corretamente. Durante os testes com wget, me deparei com o seguinte erro nos logs do NGINX:

open() "/var/cache/nginx/fastcgi_temp/..." failed (13: Permission denied)

Esse erro acontece quando o processo do NGINX não consegue acessar os arquivos temporários que o PHP-FPM está tentando enviar como resposta. No meu caso, o FastCGI estava usando o socket do PHP 7.4, e o NGINX não tinha permissão para acessar os arquivos temporários dentro de /var/cache/nginx/fastcgi_temp.

Cuidado com permissões

Ao listar a estrutura da pasta, percebi que o dono e grupo das subpastas estavam misturados:

ls -lha /var/cache/nginx

Resultado inicial:

drwx------ 12 nginx nginx 4.0K fastcgi_temp

Por padrão, o ideal é que:

A pasta (fastcgi_temp, proxy_temp, etc.) seja de propriedade nginx:root
O conteúdo interno (arquivos e subpastas) fique com nginx:nginx

Isso garante que só o processo do NGINX possa escrever e ler dentro dessas pastas, sem comprometer a estrutura principal mantida pelo root.

Solução que apliquei

Ajustei o dono das subpastas para nginx:root:

sudo chown nginx:root /var/cache/nginx/*/

Em seguida, alterei recursivamente o dono dos arquivos dentro dessas pastas para nginx:nginx:

sudo find /var/cache/nginx/ -mindepth 2 -exec chown nginx:nginx {} \;

Com isso, os arquivos temporários passaram a ser lidos normalmente, e o erro desapareceu.

Finalizei com um reload no NGINX:

sudo systemctl reload nginx

Dica: valide o usuário do processo do NGINX

Use:

ps -ef | grep nginx

No meu caso, o processo estava rodando com o usuário nginx, então as permissões acima estavam corretas. Se o seu estiver rodando como www-data, substitua os comandos conforme necessário.

Um pouco da experiência

Como trabalho com infraestrutura e automações em ambientes cloud, é comum lidar com detalhes assim que não aparecem em tutoriais ou docs simplificadas. Essa foi mais uma situação onde precisei entender o funcionamento interno do NGINX e PHP-FPM para resolver um problema de permissão sutil, mas crítico para o funcionamento do sistema.

Esses pequenos ajustes fazem toda diferença em produção, principalmente quando usamos cache, sockets e servimos arquivos via FastCGI.

Se você curte esse tipo de dica e debug, me segue aqui no dev.to ou dá um like no post