Rodou bin/magento como root: como devolver as permissões certas

Confirme que foi isso

Da raiz do Magento, uma linha responde:

find var generated pub/static pub/media app/etc -user root | head -20

Se voltar vazio, o problema é outro. Se voltar lista, você achou. Agora descubra quem deveria ser o dono, olhando com que usuário o PHP roda:

ps -o user= -C php-fpm | sort -u
stat -c '%U %G' pub/index.php

Na maioria dos servidores você vai ver dois nomes diferentes e é assim mesmo: um usuário dono dos arquivos, que é quem faz deploy e roda a CLI, e o usuário do servidor web, que precisa apenas escrever nas pastas de trabalho. A Adobe chama esse arranjo de configuração de dois usuários, e é o recomendado em produção.

Vale olhar também o que o Magento estava tentando dizer antes de ficar mudo:

tail -50 var/log/exception.log
ls -la var/report/ | tail -5

O bloco que conserta

Primeiro devolva o dono. Troque deploy pelo usuário dono dos arquivos e www-data pelo grupo do servidor web:

cd /var/www/html/magento2
chown -R deploy:www-data .

Depois rode o bloco oficial da Adobe, que ajusta a permissão de grupo nas pastas que o PHP precisa escrever:

find var generated vendor pub/static pub/media app/etc -type f -exec chmod g+w {} +
find var generated vendor pub/static pub/media app/etc -type d -exec chmod g+ws {} +
chmod u+x bin/magento

A parte que costuma passar batido é o s do segundo comando. O g+s em diretório é o setgid: todo arquivo novo criado ali herda o grupo do diretório em vez do grupo primário de quem criou. É isso que faz o arranjo continuar funcionando amanhã, quando o deploy criar arquivo novo.

Por fim, limpe o que ficou com dono errado e recomece do zero:

rm -rf var/cache/* var/page_cache/* var/view_preprocessed/*
sudo systemctl reload php8.4-fpm

O reload é pra derrubar o OPcache, que pode estar segurando uma versão antiga do que você acabou de mexer.

Pra não acontecer de novo

A regra da Adobe é curta: todo comando de CLI do Magento roda com o usuário dono dos arquivos. Nem root, nem o usuário do servidor web.

Na prática:

• Entre no servidor como o usuário de deploy, ou use sudo -u deploy php bin/magento .... Nunca sudo php bin/magento seco.
• O cron do Magento também. Se o crontab estiver no root e o deploy for outro usuário, o cron recria a bagunça toda madrugada. O php bin/magento cron:install instala as linhas no crontab de quem está rodando o comando — rode como o dono dos arquivos.
• Confira a umask. O app/bootstrap.php aplica 002 por padrão, o que já dá escrita ao grupo. Se você precisar de outro valor, coloque um arquivo chamado magento_umask na raiz com o valor em octal. Umask 022 tira a escrita do grupo e você cai no mesmo problema por outro caminho.

Se o servidor tem vários devs e ninguém lembra dessas regras, ACL resolve melhor que combinado verbal. Mas comece pelo básico: usuário certo, grupo certo e setgid nas pastas de trabalho.