Permission denied no Linux: 10 casos, incluindo /dev/null
Permission denied é um erro do Linux que aparece quando a sua conta atual não tem permissão para usar aquele arquivo, pasta ou comando. Escolha o seu caso pelo nome do comando e pelo caminho no início da linha de erro, confira as permissões e o dono com ls -l e execute de novo com as permissões ou a conta certas para resolver.
A saída abaixo veio da conta root de um servidor AlmaLinux 9.8 e de uma conta comum de um servidor Debian 12; os nomes de conta e de host e o horário na saída de /dev/null são valores de exemplo.
1️⃣ Como encontrar a causa do Permission denied
A linha de erro termina no formato [comando: alvo: Permission denied], e o nome do comando e o caminho que vêm antes mostram onde houve o bloqueio. No diagrama abaixo, escolha a mensagem de erro parecida com a da sua tela para ver o comando a conferir primeiro e o trecho deste artigo a ler.
2️⃣ Erros Permission denied mais comuns
🔲 Permissões de leitura e escrita de arquivos
Para ler um arquivo, a conta precisa da permissão de leitura (r); para alterá-lo ou criar um novo, da permissão de escrita (w). O secret.txt, com permissões 600, só pode ser lido e gravado pelo dono, root.
ls -l secret.txt-rw------- 1 root root 16 Oct 29 00:29 secret.txtrunuser -u daemon -- cat secret.txtcat: secret.txt: Permission deniedAo ler o mesmo arquivo com outra conta, daemon, a leitura foi recusada na hora. Criar um arquivo dentro de uma pasta sem permissão de escrita dá o mesmo erro: no servidor Debian 12, com uma conta comum, o touch foi bloqueado numa pasta lock com permissões 000.
touch ~/touchtest/lock/x.txttouch: cannot touch '/home/user/touchtest/lock/x.txt': Permission deniedNa primeira coluna do ls -l, veja se há r e w para o dono, o grupo e as outras contas, nessa ordem, e depois adicione permissões só à conta que precisa delas com chmod ou troque o dono com chown.
🔲 Permissão para atravessar pastas
Mesmo que as permissões do arquivo estejam certas, você não chega até ele se uma pasta no meio do caminho não tiver a permissão x. Numa pasta, x é a permissão para atravessá-la e entrar, e r é a permissão para ler a lista de nomes que ela contém.
ls -ld web web/cssdrw-r--r-- 3 root root 35 Oct 29 00:29 web
drw-r--r-- 2 root root 23 Oct 29 00:29 web/cssrunuser -u daemon -- ls -l webls: cannot access 'web/css': Permission denied
ls: cannot access 'web/index.html': Permission denied
total 0
d????????? ? ? ? ? ? css
-????????? ? ? ? ? ? index.htmlA pasta web só tem r, então o daemon conseguiu ler os nomes dentro dela, css e index.html, mas sem x as permissões e os tamanhos ficaram como pontos de interrogação. Ao contrário, a pasta site, que tem x mas não tem r, bloqueou a listagem, enquanto um arquivo cujo nome já era conhecido pôde ser lido.
ls -ld sitedrwx--x--x 2 root root 24 Oct 29 00:29 siterunuser -u daemon -- ls sitels: cannot open directory 'site': Permission deniedrunuser -u daemon -- cat site/index.html<h1>index</h1>Se o caminho for longo, use ls -ld para verificar pasta por pasta, de cima para baixo, se há x, e adicione à pasta bloqueada apenas o x de que a conta precisa para passar.
🔲 Permissão de execução
Para executar um script como ./nome do arquivo, o arquivo precisa ter a permissão x. O deploy.sh, com permissões 644, teve a execução recusada.
ls -l deploy.sh-rw-r--r-- 1 root root 8 Oct 29 00:29 deploy.sh./deploy.shbash: line 1: ./deploy.sh: Permission deniedDepois de adicionar x ao dono com chmod u+x, a primeira coluna mudou para [-rwxr--r--].
chmod u+x deploy.shls -l deploy.sh-rwxr--r-- 1 root root 8 Oct 29 00:29 deploy.shSe a execução for recusada mesmo com a permissão x, verifique se o sistema de arquivos onde está o arquivo foi montado com noexec.
🔲 Leitura de informações reservadas ao root
Uma conta comum não consegue ler as informações que o sistema reserva ao root, como processos iniciados pelo root ou dados de senha de outras contas. No servidor Debian 12, abrir com uma conta comum a pasta fd do processo 1 deu erro de permissão.
ls /proc/1/fdls: cannot open directory '/proc/1/fd': Permission deniedchage -l daemonchage: Permission denied.Os dados de expiração de senha de outra conta também foram bloqueados pelo mesmo motivo; o /etc/shadow, que guarda esses dados, é um arquivo que os usuários comuns não podem ler. Nesses erros, não amplie as permissões: execute o comando de novo com sudo ou como root.
🔲 Quando o > é bloqueado mesmo com sudo
O sudo executa como root só o comando escrito depois dele, enquanto abrir um arquivo para o redirecionamento (>) é feito pelo shell da conta atual antes de o comando rodar. Por isso, se você redirecionar a saída de sudo echo para um arquivo que só o root pode gravar, a linha de erro começa com o nome do shell, no formato [bash: caminho do arquivo: Permission denied].
sudo echo x > /root/test.txtPara fazer também o redirecionamento como root, envolva a linha inteira com sh -c para que o próprio shell rode com sudo; o manual oficial do sudo também dá um exemplo de execução dentro de sh -c para o redirecionamento funcionar.
sudo sh -c 'echo x > /root/test.txt'O tee recebe a entrada padrão e grava direto nos arquivos indicados, então, ao executar o tee com sudo, quem abre o arquivo é o tee com permissão de root. O tee também mostra na tela mais uma vez o que recebe.
echo x | sudo tee /root/test.txt🔲 Acesso SSH recusado
Se antes de Permission denied aparecer [conta@endereço do servidor:] e entre parênteses houver um método de autenticação como publickey, o acesso foi recusado na etapa de autenticação, e o lugar a conferir é diferente das permissões de arquivos. No servidor, o sshd tem StrictModes no valor padrão yes, então, antes de aceitar o login, verifica as permissões e o dono da pasta pessoal e dos arquivos daquela conta. Se qualquer um entre a pasta pessoal, a pasta ~/.ssh e o ~/.ssh/authorized_keys puder ser gravado por outra conta, o sshd não usa esse arquivo de chaves; por isso, confira com ls -ld que nenhum dos três dá permissão w a outras contas.
⌨️ Simulador de Permission denied
O simulador abaixo começa na conta root, e com runuser você vira outra conta, daemon, e vê por conta própria a saída quando a leitura de arquivos, a passagem por pastas e a permissão de execução são bloqueadas.
3️⃣ Erros Permission denied raros
Se for recusado mesmo com as permissões certas, algo fora dos bits de permissão bloqueou, como uma política do SELinux ou uma montagem noexec. Se a execução for recusada até como root, verifique se o arquivo não tem nenhum bit x.
Num servidor com o SELinux ativado, o Permission denied aparece quando uma política do SELinux bloqueia, mesmo com os bits de permissão certos; nesse caso, confira primeiro os registros de negação do SELinux. Nos servidores em que o daemon audit está rodando, as negações ficam em /var/log/audit/audit.log como [avc: denied], junto com a ação bloqueada, o nome do comando (comm) e o nome do alvo (name).
Veja com getenforce se o SELinux está ativado e rode ausearch como root para conferir as negações de hoje.
getenforceausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts todayNo daemon rsync, o [Permission denied (13)] ao receber arquivos também foi um caso de SELinux bloqueando o acesso ao caminho do módulo.
Num sistema de arquivos montado com noexec, não dá para executar arquivos diretamente, então, mesmo com x aparecendo no ls -l, eles são recusados com [bash: caminho do script: Permission denied]. Passe a pasta para findmnt -T e veja onde ela está montada e com quais opções; se noexec estiver entre as opções, é este o caso.
findmnt -T /tmp -o TARGET,OPTIONSO root passa pela maioria das verificações de permissão, mas a execução só é permitida quando pelo menos um entre dono, grupo e outras contas tem x. Por isso, um script sem nenhum x é recusado mesmo quando o root o executa com ./.
Ao executar com ./ na conta root o deploy.sh, cuja primeira coluna era [-rw-r--r-- 1 root root], apareceu [bash: line 1: ./deploy.sh: Permission denied].
🔲 Quando o /dev/null virou um arquivo comum
Se, logo depois de entrar por SSH com uma conta comum, as linhas abaixo aparecerem em sequência antes do prompt do shell, verifique primeiro se o /dev/null, o dispositivo de caracteres que todas as contas usam para descartar a saída, virou um arquivo comum do root. O número de linhas varia de servidor para servidor conforme a quantidade de scripts profile lidos no login, e no mesmo servidor o erro não apareceu depois de trocar para o root.
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
...ls -l /dev/null-rw-r--r-- 1 root root 55 Jan 10 09:00 /dev/nullstat -c %F /dev/nullregular fileA primeira coluna era [-rw-r--r--] e no lugar do tamanho aparecia 55: o texto de erro que outros comandos descartaram tinha se acumulado no arquivo. Se uma linha de comandos de limpeza com o formato abaixo rodar como root, o rm apaga o arquivo de dispositivo, e o redirecionamento 2>/dev/null do comando seguinte cria com o mesmo nome um novo arquivo comum do root.
rm -f /dev/null 2>/dev/nullExecute a linha abaixo como root. Criando o novo dispositivo com um nome ao lado e depois sobrescrevendo com mv, o nome nunca fica vago, então não sobra brecha para outro redirecionamento criar de novo um arquivo comum entre apagar e criar.
mknod -m 666 /dev/null.new c 1 3 && mv -f /dev/null.new /dev/null && ls -l /dev/nullcrw-rw-rw- 1 root root 1, 3 Jan 10 09:05 /dev/nullstat -c %F /dev/nullcharacter special fileO [c 1 3] do mknod é o número do /dev/null na lista de números de dispositivo do kernel. Depois da recuperação, o echo x > /dev/null numa conta comum também terminou sem erro. Reiniciar também pode trazê-lo de volta, mas a linha acima, que não para o servidor, é mais rápida.
| Verificar | Antes da correção | Depois da correção |
|---|---|---|
| Primeira coluna do ls -l | -rw-r--r-- | crw-rw-rw- |
| Tamanho no ls -l | 55 | 1, 3 |
| stat -c %F | regular file | character special file |
| Gravação com conta comum | Permission denied | Sem erro |
Mande a saída que quer descartar só até >/dev/null ou 2>/dev/null e, a não ser para recuperá-lo, nunca coloque /dev/null como alvo de rm ou mv.
🔢 FAQ & conteúdo recomendado
Servidor web · 403
Erro 403 do Apache depois de instalar o APM (403 Forbidden)
Artigo sobre um caso em que o servidor web não conseguia ler a pasta web, deixou Permission denied no error_log e mostrou 403.
Servidor web · 503
Erro 503 depois de instalar o APM
Artigo que confere pelo error.log um caso em que o Apache não conseguiu se conectar ao socket do php-fpm e deu 503.
ℹ️ Aviso de afiliados
O conteúdo deste site contém links de afiliados. Quando um visitante compra um produto ou serviço por meio de um desses links, o site recebe uma comissão do vendedor. O valor que o comprador paga (em promoções, ele diminui ↓) não aumenta por causa disso. Preços, descontos e informações de estoque valem para o momento em que o texto foi escrito e podem ter mudado, por isso confirme com o vendedor antes de comprar. Os produtos são escolhidos e avaliados por critérios próprios, e o recebimento de comissão não influencia a ordem de apresentação nem o conteúdo das avaliações.