Permissões de arquivos num VPS Linux: chmod, chown e o Permission denied

VPS e ServidoresAdministração e problemas·· 1.111 visualizações· 4 min de leitura

Um “Permission denied”, ou um 403 num site, quase sempre é uma de duas coisas: o dono do arquivo não é quem o serviço usa, ou falta uma permissão no arquivo ou numa das pastas do caminho. Veja com ls -l quem é o dono e o que está permitido, e com namei -l /caminho/completo a primeira pasta do caminho que bloqueia. Corrige-se com chown (mudar o dono) e chmod (mudar as permissões). Num VPS não gerenciado, isto é seu.

Ler o que o ls -l diz

Uma linha como -rw-r--r-- 1 deploy www-data 1200 out 10 site.php tem três partes. Os primeiros dez caracteres são o tipo e as permissões (- arquivo, d pasta; depois três grupos de três: dono, grupo, os outros, cada um com r ler, w escrever, x executar). Depois vêm o dono (deploy) e o grupo (www-data).

Número Quer dizer Quando se usa
644 Dono lê e escreve; grupo e outros só leem Arquivos de um site
755 Dono lê, escreve, executa; os outros leem e executam Pastas, e programas
600 Só o dono lê e escreve Segredos: chaves, arquivos com senhas
700 Só o dono entra Pastas privadas, como ~/.ssh
777 Todo mundo faz tudo Nunca. Resolve o sintoma e abre a porta a quem entrar por qualquer outro site.

Passo a passo para um site que dá 403 ou “Permission denied”

1 Descubra quem é o serviço. ps aux | grep -E "nginx|apache|httpd|php-fpm" | head. Em Debian e Ubuntu costuma ser www-data; em AlmaLinux e Rocky, nginx ou apache.
2 Veja o caminho inteiro. namei -l /var/www/seudominio.tld/public/index.php mostra as permissões de cada pasta até o arquivo. O servidor tem de poder atravessar (permissão x) todas as pastas do caminho, e não só ler o arquivo. Uma pasta pessoal fechada (/home/usuário com 700) bloqueia tudo o que está dentro.
3 Acerte o dono. Se o site é gerenciado por um usuário seu e servido por outro, dê o grupo certo: sudo chown -R deploy:www-data /var/www/seudominio.tld. Ou deixe o serviço ser dono apenas das pastas onde precisa de escrever (envios, caches).
4 Acerte as permissões com valores sensatos: sudo find /var/www/seudominio.tld -type d -exec chmod 755 {} \; e sudo find /var/www/seudominio.tld -type f -exec chmod 644 {} \;.
5 Dê escrita só onde é preciso. Uma pasta de envios precisa de escrita para o serviço (por exemplo chmod 775 com o grupo do serviço); o resto do site não.
6 Teste de novo e leia o log de erros. Se continua negado depois de tudo certo, pode ser o SELinux ou o AppArmor: quando bloqueiam um serviço.
Cuidado com o -R no lugar errado. chown -R ou chmod -R numa pasta mais acima do que pretendia (a raiz /, /etc, /home) pode partir o sistema inteiro: o SSH deixa de aceitar chaves com permissões largas, e programas do sistema precisam dos seus donos. Leia o caminho duas vezes antes de clicar em Enter.
Não use o root como dono do site. Se uma tarefa de root escreve na pasta, os arquivos ficam do root e o site não os consegue alterar. Execute essa tarefa como o usuário certo: o cron que não corre.
Os segredos pedem 600: um arquivo .env com senhas lê-se só pelo dono (variáveis de ambiente e segredos). E um serviço do systemd corre com o usuário que lhe der: executar o seu programa como serviço.

Fechou-se fora do servidor ao mexer em permissões do sistema? A console do painel entra sem passar pela rede: diga-nos o que fez.

Abrir um pedido de suporte

VEJA TAMBÉM

SELinux ou AppArmor a bloquear um serviço

Executar o seu programa como serviço do systemd

Variáveis de ambiente e segredos

Manter o seu VPS seguro

PRODUTO RECOMENDADO

Servidor VPS com acesso root

Recursos só seus, o sistema que escolher, reinstalação quando quiser. desde R$ 46,20/mês (plano de 3 anos, com cupom)

Ver planos
Esta resposta foi útil? Sua resposta nos ajuda a melhorar este artigo.