Corrigindo Permission Denied no Ubuntu - Guia de chmod, chown e sudo

Corrigindo Permission Denied no Ubuntu - Guia de chmod, chown e sudo
Tempo de leitura: Cerca de 10 min Dificuldade: Intermediário

O que você vai aprender

  • Como diagnosticar rapidamente erros de Permission denied no Ubuntu
  • Quando usar chmod, chown ou sudo
  • Como evitar erros comuns (como abrir permissões demais)

Resumo Rápido

Permission denied geralmente se encaixa em uma dessas categorias:

  1. Sem permissão de execução -> chmod +x
  2. Proprietário/grupo errado -> chown / chgrp
  3. Requer privilégios de administrador -> Execute com sudo
  4. Não consegue entrar no diretório (sem permissão x) -> Verifique permissões do diretório

Comece com ls -la (ou namei -l) para ver quem está bloqueando o que.

Pré-requisitos

  • SO: Ubuntu
  • Shell: bash
  • Permissões: Acesso sudo assumido (contate o administrador se indisponível)

1. Verifique os sintomas

Conclusão: O tipo de erro — arquivo, script ou diretório — determina qual caminho de correção seguir.

Exemplo: Não consegue ler um arquivo

$ cat /path/to/file
cat: ...: Permission denied

Exemplo: Não consegue executar um script

$ ./script.sh
bash: ./script.sh: Permission denied

Exemplo: Não consegue entrar em um diretório

$ cd /path/to/dir
bash: cd: ...: Permission denied

2. Verifique as permissões (ls -la)

Conclusão: Execute ls -la — os bits rwx para proprietário, grupo e outros revelam o que está faltando.

$ ls -la /path/to/target

Lendo as permissões

  • r: leitura
  • w: escrita
  • x: execução (ou entrada para diretórios)

Três grupos: proprietário | grupo | outros

Exemplos:

  • -rw-r--r--: Proprietário pode escrever, outros só podem ler
  • drwxr-x---: Proprietário tem acesso total, grupo pode ler/entrar, outros não têm acesso

Caso A: Script não executa (sem x)

Conclusão: Execute chmod +x quando o bit x está ausente — ele adiciona apenas execução, nada mais.

Verifique:

$ ls -la script.sh

Se você vê -rw-r--r-- (sem x), adicione permissão de execução:

$ chmod +x script.sh

Isso apenas adiciona permissão de "execução". Não é necessário ampliar permissões de leitura/escrita.

Caso B: Não consegue escrever (sem w / proprietário errado)

Conclusão: O acesso de escrita é definido pelo diretório — use chown ou sudo conforme apropriado.

Permissões de escrita dependem do diretório.

Se você deveria ser o dono do local -> Corrija o proprietário (Caso C)

Se é um diretório do sistema (/etc, /var, /usr) -> Use sudo (Caso D)

Caso C: Proprietário/grupo errado (chown/chgrp)

Conclusão: Use chown user:group /path — sempre verifique o caminho antes de adicionar -R.

Alterar proprietário (exemplo: usuário é ubuntu):

$ sudo chown ubuntu:ubuntu /path/to/dir

Recursivo (cuidado):

$ sudo chown -R ubuntu:ubuntu /path/to/dir

Atenção: -R afeta tudo sob o caminho. Verifique duas vezes antes de executar.

Alterar apenas o grupo:

$ sudo chgrp www-data /path/to/dir

Caso D: Precisa de privilégios de administrador (sudo)

Conclusão: Use sudo para arquivos do sistema — acesso elevado temporário, proprietário inalterado.

Arquivos e serviços do sistema requerem acesso de administrador:

$ sudo vim /etc/nginx/nginx.conf
$ sudo systemctl restart nginx

Caso E: Não consegue entrar no diretório (sem x)

Conclusão: Diretórios precisam de x para entrar — corrija com chown, não com chmod 777.

Permissão negada no cd geralmente significa que o diretório não tem permissão de execução (entrada).

$ ls -ld /path/to/dir

Se você deveria poder entrar, corrija o proprietário ou grupo (Caso C). Não use chmod 777 descuidadamente.

3. Rastreie o caminho (namei)

Conclusão: Execute namei -l /path — mostra as permissões de cada diretório e revela o bloqueio.

Quando você não consegue descobrir onde está o bloqueio em um caminho longo:

$ namei -l /path/to/target

Isso mostra as permissões de cada diretório no caminho, facilitando encontrar o diretório com problema.

4. O que NÃO fazer

Conclusão: Nunca use chmod 777 ou chown -R / — ambos criam brechas ou destroem o sistema.

Próximas leituras