Diego Brito
Morreremos e nunca saberemos o que é a vida!
Membro da equipe
Administrador
Parceiros
Melhor pôster do mês
WordPress no Nginx: corrigindo permissões, upload_max_filesize e atualização com PHP-FPM
Se o WordPress estiver rodando em Nginx + PHP-FPM e apresentar erros como:- "Required File Permissions to import the templates from Starter Templates are missing."
- "O arquivo enviado excede a diretiva upload_max_filesize em php.ini."
- "A atualização não pode ser instalada porque não foi possível copiar alguns arquivos."
- "Isso geralmente ocorre devido a permissões de arquivo inconsistentes."
Neste exemplo, o WordPress está instalado em:
/usr/share/nginx/html/lrartigos
O PHP utilizado é o PHP 8.2-FPM.
1. Verificar o proprietário do WordPress
Primeiro confira o proprietário dos arquivos:ls -ld /usr/share/nginx/html/lrartigos<br>ls -ld /usr/share/nginx/html/lrartigos/wp-content<br>ls -ld /usr/share/nginx/html/lrartigos/wp-content/uploads<br>
Em um ambiente Nginx + PHP-FPM comum, o usuário do PHP-FPM é www-data.
Confira:
grep -E "^(user|group)\s*=" /etc/php/8.2/fpm/pool.d/www.conf
O resultado esperado:
user = www-data<br>group = www-data
Se necessário, ajuste o proprietário:
chown -R www-data:www-data /usr/share/nginx/html/lrartigos/wp-content
Para corrigir permissões de arquivos e diretórios:
find /usr/share/nginx/html/lrartigos/wp-content -type d -exec chmod 755 {} \;
find /usr/share/nginx/html/lrartigos/wp-content -type f -exec chmod 644 {} \;
Não utilize chmod -R 777.
2. Testar se o www-data consegue escrever
Antes de alterar outras configurações, teste diretamente:su -s /bin/bash www-data -c 'touch /usr/share/nginx/html/lrartigos/wp-content/teste-permissao.txt && echo OK || echo ERRO'
Se retornar:
OK<br>
o usuário www-data consegue escrever pelo shell.
Remova o arquivo:
rm -f /usr/share/nginx/html/lrartigos/wp-content/teste-permissao.txt
Também podemos testar o diretório utilizado pelo Starter Templates:
su -s /bin/bash www-data -c 'mkdir /usr/share/nginx/html/lrartigos/wp-content/uploads/ai-builder/teste-pasta && echo OK || echo ERRO'
Remova o teste:
rm -rf /usr/share/nginx/html/lrartigos/wp-content/uploads/ai-builder/teste-pasta
3. Verificar o FS_METHOD do WordPress
Abra:nano /usr/share/nginx/html/lrartigos/wp-config.php
Verifique se existe:
define('FS_METHOD', 'direct');
Essa configuração permite que o WordPress utilize diretamente o filesystem.
Para verificar pelo terminal:
grep -E "FS_METHOD|FS_CHMOD|FS_DIRECT" /usr/share/nginx/html/lrartigos/wp-config.php
4. O problema que pode passar despercebido: ProtectSystem
Mesmo que o Linux mostre que www-data possui permissão de escrita, o PHP-FPM pode estar impedido de escrever devido às proteções do systemd.Verifique:
systemctl cat php8.2-fpm
Se aparecer:
ProtectSystem=full
o PHP-FPM está sendo executado com uma proteção que pode impedir gravações em determinadas partes do sistema.
Isso pode causar situações aparentemente contraditórias:
www-data pelo terminal → consegue escrever<br>PHP-FPM → Read-only file system<br>
Para confirmar, podemos testar diretamente pelo PHP.
Crie temporariamente:
nano /usr/share/nginx/html/lrartigos/teste.php
Coloque:
<?php
$arquivo = '/usr/share/nginx/html/lrartigos/wp-content/uploads/ai-builder/teste-php.txt';
$resultado = @file_put_contents($arquivo, 'teste');<br><br>if ($resultado !== false) {<br> echo 'ESCRITA PHP: OK<br>';<br> unlink($arquivo);<br>} else {<br> echo 'ESCRITA PHP: ERRO<br>';<br> var_dump(error_get_last());<br>}<br>
Acesse pelo navegador:
Se aparecer:
ESCRITA PHP: ERRO
e:
Read-only file system
a proteção do PHP-FPM é uma forte candidata à causa.
Depois do teste, remova o arquivo:
rm -f /usr/share/nginx/html/lrartigos/teste.php
5. Liberar o diretório do WordPress no PHP-FPM
Não é necessário remover:ProtectSystem=full
Essa proteção é útil para segurança.
Em vez disso, crie um override:
systemctl edit php8.2-fpm
Adicione:
[Service]<br>ReadWritePaths=/usr/share/nginx/html/seu_site
Salve e feche.
Depois:
systemctl daemon-reload<br>systemctl restart php8.2-fpm
Confirme:
systemctl show php8.2-fpm -p ProtectSystem -p ReadWritePaths
O esperado:
ProtectSystem=full<br>ReadWritePaths=/usr/share/nginx/html/seu_site
Dessa forma, o PHP-FPM continua com ProtectSystem=full, mas pode escrever dentro do diretório específico do WordPress.
6. Corrigindo o upload_max_filesize
Outro erro bastante comum é:O arquivo enviado excede a diretiva upload_max_filesize em php.ini.
Como o site utiliza PHP-FPM 8.2, edite:
nano /etc/php/8.2/fpm/php.ini
Localize:
upload_max_filesize = 2M
Por exemplo, altere para:
upload_max_filesize = 128M
Também ajuste:
post_max_size = 128M
Para instalações WordPress maiores, pode ser útil:
memory_limit = 256M<br>max_execution_time = 300<br>max_input_time = 300
Depois reinicie:
systemctl restart php8.2-fpm
Confira:
php-fpm8.2 -i | grep -E "upload_max_filesize|post_max_size|memory_limit|max_execution_time|max_input_time"
7. Se aparecer erro 413 no Nginx
Depois de aumentar o limite do PHP, o Nginx também pode bloquear arquivos grandes.O erro normalmente será:
413 Request Entity Too Large<br>
Verifique a configuração:
grep -R "client_max_body_size" /etc/nginx/ 2>/dev/null
Se necessário, adicione no servidor Nginx:
client_max_body_size 128M;
Depois teste:
nginx -t
Se estiver tudo correto:
systemctl reload nginx
8. Erro ao atualizar o WordPress
Outro problema possível é:A atualização não pode ser instalada porque não foi possível copiar alguns arquivos.
Isso geralmente ocorre devido a permissões de arquivo inconsistentes.
wp-admin/includes/update-core.php<br>
Se o Starter Templates já foi corrigido, mas a atualização do WordPress continua falhando, isso acontece porque liberar somente:
wp-content<
não é suficiente.
Durante uma atualização, o WordPress precisa substituir arquivos em:
wp-admin<br>wp-includes
e também em outras partes da instalação.
Por isso, para esse site, o ReadWritePaths deve ser:
[Service]
ReadWritePaths=/usr/share/nginx/html/lrartigos
e não somente:
ReadWritePaths=/usr/share/nginx/html/lrartigos/wp-content
Depois:
systemctl daemon-reload
systemctl restart php8.2-fpm
A atualização poderá novamente escrever nos arquivos necessários.
9. Verificação final
Confira o PHP-FPM:systemctl status php8.2-fpm --no-pager
Confira o override:
systemctl show php8.2-fpm -p ProtectSystem -p ReadWritePaths
Confira o Nginx:
nginx -t
E:
systemctl reload nginx
Confira as permissões:
ls -ld /usr/share/nginx/html/lrartigos
ls -ld /usr/share/nginx/html/lrartigos/wp-content
ls -ld /usr/share/nginx/html/lrartigos/wp-content/uploads
ls -ld /usr/share/nginx/html/lrartigos/wp-content/uploads/ai-builder
10. Resultado
Com a configuração correta, o servidor pode manter:ProtectSystem=full
enquanto permite que o PHP-FPM escreva no WordPress através de:
ReadWritePaths=/usr/share/nginx/html/pasta_do_site
E o PHP pode utilizar:
upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 256M
max_execution_time = 300
max_input_time = 300
Isso resolve três problemas diferentes que podem aparecer juntos em uma instalação WordPress com Nginx + PHP-FPM:
- Starter Templates não consegue gravar arquivos.
- Uploads excedem upload_max_filesize.
- WordPress não consegue copiar arquivos durante uma atualização.
rm -f /usr/share/nginx/html/lrartigos/teste.php
Não utilize chmod 777 como solução padrão. Primeiro verifique o usuário do PHP-FPM, as permissões e as restrições do serviço systemd.