Quase todo administrador Linux já topou com o "Permission denied". Tentamos rodar um script, abrir um arquivo, entrar em um diretório ou conectar via SSH, e o terminal devolve a mensagem de bloqueio. A reação mais comum costuma ser jogar um chmod 777 em cima e seguir em frente, o que resolve o sintoma e abre buracos de segurança no sistema.
Neste guia vamos mostrar como diagnosticar a causa real do erro, identificar em qual camada o acesso está sendo bloqueado e aplicar a correção mínima necessária. Cobrimos o modelo POSIX, o uso correto de chmod e chown, cenários típicos como chaves SSH e diretórios web, além de camadas adicionais como SELinux e atributos estendidos.
Para os exercícios práticos, recomendamos um servidor descartável. Um VPS Linux na Serverspace serve bem para testar os comandos em ambiente isolado. Os exemplos funcionam de forma idêntica em Ubuntu, Debian, AlmaLinux e Rocky.
O que significa o erro "Permission denied"
A mensagem aparece quando o kernel do Linux recusa uma operação porque o usuário atual não tem direitos suficientes sobre o arquivo ou diretório envolvido. O texto é praticamente sempre o mesmo, porém as causas variam bastante.
Os contextos mais frequentes incluem a tentativa de executar um script sem o bit de execução, a leitura de um arquivo de outro usuário, a escrita em diretórios do sistema como /etc ou /var/www, o acesso via cd a uma pasta sem o bit x, e a autenticação SSH com chaves cujas permissões estão muito abertas.
Antes de aplicar qualquer correção, vale entender que o Linux verifica acesso em três camadas. A primeira são as permissões POSIX clássicas (rwx para dono, grupo e outros). A segunda são as ACLs estendidas, que permitem regras finas para usuários e grupos específicos. A terceira são os módulos de segurança obrigatória: SELinux em sistemas RHEL e derivados, AppArmor em Ubuntu e Debian.
Terminologia: como o Linux organiza permissões
O controle de acesso se baseia em três categorias de sujeitos e três tipos de operação. As categorias são: dono do arquivo (user, u), grupo do arquivo (group, g) e outros usuários do sistema (others, o). Cada arquivo tem um único dono e um único grupo associado, definidos no momento da criação.
Os tipos de operação são: leitura (read, r), escrita (write, w) e execução (execute, x). Para arquivos, o significado é direto. Em diretórios há uma sutileza importante: leitura permite listar o conteúdo, escrita permite criar e remover arquivos dentro, e execução permite atravessar o diretório, ou seja, fazer cd e acessar arquivos pelo caminho completo.
A saída de ls -l mostra esse modelo em ação:
-rwxr-xr-- 1 maria devs 2048 Mar 10 14:20 deploy.shO primeiro caractere indica o tipo (- arquivo regular, d diretório, l link simbólico). Os próximos nove caracteres formam três triplas, uma para cada categoria: rwx para o dono, r-x para o grupo, r-- para outros.
Existem duas formas de definir permissões com chmod. A simbólica usa letras e operadores (chmod u+x script.sh adiciona execução para o dono). A octal soma os valores 4 (r), 2 (w) e 1 (x) por categoria, gerando três dígitos. As combinações mais usadas no dia a dia:
| Octal | Símbolo | Aplicação típica | Para que serve |
|---|---|---|---|
| 644 | rw-r--r-- | Arquivos de texto, configs | Dono edita, demais leem |
| 755 | rwxr-xr-x | Diretórios, scripts públicos | Todos navegam e executam |
| 700 | rwx------ | Diretório ~/.ssh, dados privados | Acesso só do dono |
| 600 | rw------- | Chaves privadas SSH, .env | Leitura e escrita só do dono |
| 775 | rwxrwxr-x | Pasta de uploads colaborativa | Grupo escreve, outros leem |
Memorizar essas cinco combinações cobre a maioria das situações práticas. O resto pode ser construído a partir delas com pequenas variações.
Como o sistema de permissões funciona
Quando um processo tenta acessar um arquivo, o kernel executa uma sequência de verificações. Primeiro compara o UID do processo com o UID do dono. Se forem iguais, aplica os bits do dono. Caso contrário, verifica se algum dos grupos do usuário coincide com o grupo do arquivo e aplica os bits do grupo. Se nenhuma das condições anteriores valer, aplica a tripla outros.
Esse fluxo tem implicações importantes. Para apagar um arquivo, o que importa é a permissão de escrita no diretório que o contém, não no arquivo em si. Por isso conseguimos remover arquivos somente leitura sem obstáculos, desde que possamos escrever no diretório.
Outra implicação envolve o bit de execução em diretórios. Se /home/maria/projetos não tem o bit x para o usuário atual, nenhum arquivo dentro dele pode ser acessado, mesmo com permissões abertas. Todo o caminho até o arquivo precisa ser atravessável.
Por fim vale conhecer o umask. Quando criamos um arquivo novo, o sistema parte de 666 (arquivos) ou 777 (diretórios) e subtrai a máscara umask. O padrão 022 resulta em 644 para arquivos e 755 para diretórios.
Cenários práticos onde o erro aparece
Script shell sem permissão de execução
Criamos um script, escrevemos algumas linhas e tentamos rodar:
$ ./deploy.sh
bash: ./deploy.sh: Permission denied
A causa é que o arquivo foi criado sem o bit x. A correção é adicionar execução para o dono:
chmod u+x deploy.sh
./deploy.sh
Se o script precisa ser executado por todos os usuários, podemos usar chmod 755. Para uso pessoal, chmod 700 mantém o script privado.
Chave SSH com permissões abertas demais
Ao conectar em um servidor:
Permissions 0644 for '~/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
Esse comportamento vem do parâmetro StrictModes yes, ativado por padrão no sshd_config. O servidor recusa qualquer chave que possa ser lida por outros usuários da máquina cliente. A correção exige permissões fechadas para a chave e para o diretório:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/authorized_keys
Escrita em diretório de sistema
Tentar criar um arquivo dentro de /etc ou /var/www como usuário comum gera bloqueio imediato. A correção depende da intenção. Para alterações pontuais em arquivos do sistema, sudo resolve. Para diretórios web onde uma aplicação escreve regularmente, o caminho correto é ajustar a propriedade:
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
Acesso a arquivos de outro usuário
Se maria precisa ler arquivos criados por joao, há duas opções limpas. A primeira é colocar maria no grupo de joao e garantir leitura no grupo:
sudo usermod -aG joao maria
chmod g+r /home/joao/relatorio.txt
A segunda usa ACLs para uma regra específica sem mexer em grupos:
sudo setfacl -m u:maria:r /home/joao/relatorio.txtSistema de arquivos read-only ou atributo immutable
Em alguns casos, o próprio chmod retorna Permission denied, inclusive para o root. As causas mais prováveis são duas: o sistema de arquivos foi montado com a opção ro, ou o arquivo recebeu o atributo i (immutable) através do chattr. Para diagnosticar:
mount | grep " on / "
lsattr arquivo
Se o arquivo tem o atributo i, removemos com sudo chattr -i arquivo. Se a partição está em modo somente leitura, é necessário remontar com escrita ou ajustar o /etc/fstab.
Instrução passo a passo: diagnóstico e correção
Sempre que aparecer um Permission denied, recomendamos seguir esta sequência. Ela leva ao diagnóstico correto sem chutes.
Passo 1. Identificar dono, grupo e permissões
ls -l arquivo
ls -ld diretorio
id
groups
O comando ls -l mostra dono, grupo e os bits rwx. O comando id revela UID, GID primário e grupos suplementares do usuário atual. Comparando os dois, descobrimos em qual tripla o acesso está sendo avaliado. Para informações ainda mais detalhadas, stat fornece tudo, incluindo timestamps e número de inode:
stat arquivoPasso 2. Ajustar permissões com chmod
Com a causa identificada, ajustamos as permissões. A forma simbólica é prática para mudanças pontuais:
chmod u+x script.sh
chmod g-w arquivo.txt
chmod o=r arquivo.txt
A forma octal é melhor quando definimos um conjunto completo de uma vez:
chmod 644 config.yaml
chmod 755 deploy.sh
chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh
Para ajustes recursivos em árvores de diretórios, evite chmod -R com um único valor. Use find para separar arquivos e diretórios:
find /caminho -type d -exec chmod 755 {} \;
find /caminho -type f -exec chmod 644 {} \;
Passo 3. Corrigir propriedade com chown
Quando o problema é o dono ou o grupo do arquivo, chown resolve:
sudo chown maria arquivo.txt
sudo chown maria:devs arquivo.txt
sudo chown :devs arquivo.txt
sudo chown -R www-data:www-data /var/www
A sintaxe usuario:grupo cobre os dois ajustes em uma operação. A flag -R aplica recursivamente em diretórios e seu conteúdo.
Passo 4. Usar sudo quando faz sentido
O sudo é a ferramenta certa para operações em arquivos do sistema (/etc, /var/log, /usr) e para iniciar serviços que exigem privilégios. Para arquivos dentro de /home ou de projetos próprios, prefira corrigir a propriedade com chown em vez de rodar tudo como root, evitando criar arquivos pertencentes a root no seu diretório pessoal.
Passo 5. Verificar camadas adicionais
Se as permissões POSIX estão corretas e o erro persiste, é hora de olhar para as camadas extras. Para verificar ACLs:
getfacl arquivoSe houver entradas que negam acesso, ajuste com setfacl ou remova-as com setfacl -b.
Para verificar SELinux em sistemas RHEL, AlmaLinux ou Rocky:
getenforce
sudo ausearch -m avc -ts recent
Se getenforce retornar Enforcing e ausearch mostrar bloqueios, a política do SELinux está negando o acesso. A solução depende do contexto, podendo envolver restorecon, chcon ou ajuste de booleanos com setsebool.
Para verificar AppArmor em Ubuntu e Debian, use sudo aa-status. Se houver um perfil ativo restringindo o aplicativo, os logs em /var/log/syslog ou /var/log/audit/audit.log mostram a negação.
Erros comuns ao corrigir permissões
Listamos os deslizes que mais causam problemas e como evitá-los.
Aplicar chmod 777 em tudo é a solução mais tentadora e a pior ideia. Concede leitura, escrita e execução para qualquer usuário do sistema. Em servidores expostos, é receita pronta para invasão. Identifique o usuário ou grupo que precisa de acesso e libere apenas o necessário.
Usar chmod -R 755 em árvores mistas adiciona o bit x desnecessariamente em arquivos comuns. Use find com -type d e -type f para separar arquivos e diretórios.
Esquecer o bit x no diretório pai causa falhas mesmo com permissões abertas no arquivo. Verifique todo o caminho com ls -ld em cada nível.
Inverter a ordem de chmod e chown em scripts de provisionamento (Dockerfiles, Ansible) pode resultar em permissões incorretas se o chown alterar bits suid e sgid. A ordem segura é primeiro chown, depois chmod.
Ignorar o SELinux em CentOS, AlmaLinux e Rocky é fonte de horas perdidas. Sempre rode getenforce e ausearch quando os ajustes POSIX não resolverem.
Usar sudo onde a propriedade deveria ser corrigida cria arquivos pertencentes a root em locais errados. Se uma aplicação precisa escrever em /var/www, ajuste o dono para www-data.
Conclusão
O Permission denied é menos um obstáculo, e mais um sinal claro de que o sistema está fazendo o trabalho dele. A abordagem certa passa por entender em qual camada o bloqueio aconteceu e corrigir o ponto exato.
Com prática, decifrar uma mensagem de Permission denied vira questão de segundos. A sequência funciona em qualquer cenário: ls -l e id para diagnóstico, chmod para ajustar bits, chown para acertar a propriedade, sudo somente quando faz sentido, e verificação de ACLs e SELinux quando o resto está ok.
