Moveu o seu site para um alojamento e os plugins deixaram de instalar. Ou os ficheiros multimédia não carregam através do painel de administração. Ou uma atualização do core falha com «Could not create directory». Parece-lhe familiar?

A causa é quase sempre a mesma: permissões incorretas de ficheiros e pastas. Um servidor local (OpenServer, MAMP) corre sob o utilizador atual do Windows/macOS e perdoa tudo. Um alojamento Linux de produção não. Cada ficheiro e diretório tem um proprietário e três níveis de permissão e, se o servidor web não conseguir escrever na pasta necessária, o site quebra silenciosamente ou com um erro enigmático.

A seguir, descubra o que 755 e 644 realmente significam, como defini-los de uma vez através do FileZilla para todo o site e quais os ficheiros que exigem tratamento especial.

💡 Resumo rápido:

• O que significam os números 755 e 644 e porque é que 777 é um buraco de segurança
• Como definir permissões em massa via FileZilla em 2 passagens: primeiro as pastas, depois os ficheiros
• Que permissões precisam o wp-config.php, o .htaccess e a pasta wp-content
• Como fazer o mesmo via SSH com um comando em 5 segundos

O que significam as permissões e porque é que 777 é um desastre

Cada ficheiro e pasta num servidor Linux guarda três conjuntos de permissões: para o proprietário, para o grupo e para todos os outros. O número é uma soma de bits: 4 (leitura) + 2 (escrita) + 1 (execução, que para pastas significa poder entrar nelas).

755 para pastas decompõe-se da seguinte forma: o proprietário pode fazer tudo (7), o grupo e os outros podem ler e entrar (5). A pasta fica acessível ao servidor web para varrer e criar ficheiros e subpastas dentro dela, mas ninguém de fora pode apagá-la ou renomeá-la.

644 para ficheiros: o proprietário pode ler e escrever (6), os outros apenas podem ler (4). Os ficheiros PHP são executados pelo interpretador, não pelo sistema, portanto não precisam do bit de execução.

777 (proprietário+grupo+outros = tudo) é uma porta escancarada. Qualquer processo no servidor, incluindo scripts de sites vizinhos em alojamento partilhado, pode ler, modificar e apagar os seus ficheiros. De acordo com os dados de 2025 da WPScan, as permissões incorretas estão entre os cinco vetores de ataque mais comuns ao WordPress em alojamento partilhado. Nunca defina 777. Se um plugin ou tema exigir tais permissões, isso é um sinal de alerta.

Que permissões o WordPress considera corretas

A documentação oficial do WordPress define as permissões recomendadas da seguinte forma:

Na maioria dos alojamentos, o proprietário do sistema de ficheiros coincide com o utilizador sob o qual o PHP corre (configuração suPHP/FastCGI + suEXEC). Nesta configuração, as permissões 755/644 são suficientes: o WordPress pode escrever em wp-content/uploads, atualizar o core e os plugins e instalar temas sem escalar para 777.

Verifique se isto se aplica ao seu alojamento: vá ao painel de administração e tente instalar qualquer plugin gratuito. Se instalar sem pedir credenciais de FTP, o esquema 755/644 funciona e as permissões já estão corretas.

Como definir permissões via FileZilla: passo a passo

O FileZilla é um cliente FTP gratuito que pode alterar permissões em massa de forma recursiva. Descarregue-o do site oficial, se ainda não o tiver.

Passo 1: ligar e navegar até à raiz do WordPress

Ligue-se ao seu alojamento via FTP (login/palavra-passe são os mesmos da sua conta de alojamento, porta 21). No painel direito, navegue até à pasta raiz do site, onde estão o wp-config.php, wp-content, wp-admin e wp-includes.

Passo 2: definir 755 em todas as pastas

Selecione todos os ficheiros e pastas na raiz (Ctrl+A). Clique com o botão direito → «Permissões do ficheiro».

Na janela que se abre, introduza 755 no campo «Valor numérico». Marque a caixa de verificação «Incluir todos os subdiretórios». Defina o botão de rádio para «Aplicar apenas a diretórios». Clique em OK.

O FileZilla percorrerá todas as pastas e subpastas do site e definirá 755. O processo demora de alguns segundos a um par de minutos, dependendo do tamanho do site.

Passo 3: definir 644 em todos os ficheiros

Selecione tudo na raiz novamente (Ctrl+A), clique com o botão direito outra vez → «Permissões do ficheiro».

Agora introduza 644. Marque «Incluir todos os subdiretórios». Defina o botão de rádio para «Aplicar apenas a ficheiros». OK.

Pronto. Duas passagens (pastas e ficheiros) e todo o site fica conforme o padrão.

Método rápido via SSH: o comando find

Se tiver acesso SSH ao servidor, a mesma operação demora dois comandos e cinco segundos:

1
find /path/to/wordpress -type d -exec chmod 755 {} \;
2
find /path/to/wordpress -type f -exec chmod 644 {} \;

O primeiro percorre todas as pastas (-type d) e define 755. O segundo percorre todos os ficheiros (-type f) e define 644. Substitua /path/to/wordpress pelo caminho real para a raiz do seu site (normalmente /home/username/public_html).

Depois disso, reforce separadamente o wp-config.php:

1
chmod 600 /path/to/wordpress/wp-config.php

E o .htaccess, se tiver um (servidor Apache):

1
chmod 644 /path/to/wordpress/.htaccess

Se o seu site correr em Nginx, não existe ficheiro .htaccess, pelo que pode saltar este passo.

O que fazer se as permissões forem repostas

Situação: definiu 755/644, tudo funcionou e, uma semana depois, recebe o mesmo erro. A causa é geralmente um processo a correr sob um utilizador diferente.

Culpados típicos:

• Tarefas cron do alojamento. Alguns alojamentos executam scripts de manutenção como root e estes criam ficheiros com permissões que o servidor web não pode sobrescrever depois. Solução: peça ao suporte para configurar o cron para correr sob o seu utilizador.
• Plugin de backup de terceiros. Escreve dumps e arquivos em wp-content sob o utilizador com que corre. Verifique os logs do plugin. Se criar ficheiros sob um utilizador diferente do proprietário do site, mude para uma alternativa.
• Plugin de cache. Cria pastas de cache com permissões incorretas. Vá às definições do plugin e procure o botão «Limpar cache» ou «Repor permissões».

Correção rápida universal: repita o procedimento da secção acima (FileZilla em 2 passagens ou dois comandos find). Isto não resolve a causa raiz, mas repõe o site em condições de funcionamento.

⁉️🤔 Perguntas frequentes

E se o site falhar para um «ecrã branco da morte» depois de alterar as permissões?

Um ecrã branco (WSOD) após alteração de permissões em massa é extremamente raro, mas possível. Primeiro: ative WP_DEBUG no wp-config.php para ver o texto do erro em vez de um ecrã branco. Segundo: verifique se definiu acidentalmente 644 nas pastas (as pastas precisam do bit de execução, ou seja, 5 no final). Corrija com um comando find: find /path -type d -exec chmod 755 {} \;. Isto é suficiente na maioria dos casos. Se o site ainda não funcionar, restaure a partir do backup e altere as permissões gradualmente: primeiro no wp-content, depois na raiz, observando as reações.

Posso definir permissões através do gestor de ficheiros integrado do alojamento?

Sim, mas apenas para ficheiros e pastas individuais. Os alojamentos cPanel fornecem um Gestor de Ficheiros com «Alterar Permissões» no menu de contexto. No entanto, definir permissões recursivamente em centenas ou milhares de ficheiros através de uma interface web é praticamente impossível. Para operações em massa, use o FileZilla ou SSH.

Que permissões deve ter a pasta wp-content/uploads?

O padrão 755, como todas as outras pastas. Se um plugin ou tema criar subpastas dentro de uploads e tiver problemas, verifique o proprietário do processo (deve coincidir com o proprietário da pasta) em vez de aumentar as permissões para 777. Por vezes, o problema resolve-se adicionando define('FS_METHOD', 'direct'); ao wp-config.php.

Preciso de definir permissões nos ficheiros dentro de wp-admin e wp-includes?

Sim, o padrão 644 para ficheiros e 755 para pastas, igual ao resto do site. O procedimento do FileZilla (selecionar tudo na raiz) trata deles automaticamente.

O meu alojamento exige 777 em algumas pastas. Isto é normal?

Não. Exigir 777 é um sinal de que o PHP no servidor corre sob um utilizador diferente do proprietário dos ficheiros (por exemplo, mod_php sem suEXEC). Nesta configuração, o WordPress não consegue escrever nas pastas sem acesso «world». Opções: mude para um alojamento que use suPHP/FastCGI (a maioria dos modernos usa), ou adicione define('FS_METHOD', 'direct'); ao wp-config.php, o que por vezes é suficiente.

As permissões corretas são uma base, não uma opção

Definir 755 nas pastas e 644 nos ficheiros fecha o canal mais comum para erros «misteriosos» ao migrar um site. Dois minutos no FileZilla ou dois comandos SSH poupam horas de adivinhação sobre logs.

Se o seu site estiver num bom alojamento com suPHP/FastCGI, estas permissões são suficientes para tudo: instalar plugins, carregar multimédia e atualizações automáticas do core. Não aumente as permissões para 777, mesmo que as instruções de um plugin antigo o peçam. E adicione o wp-config.php como um item separado: chmod 600. Contém a palavra-passe da base de dados e pessoas de fora não precisam de acesso a ela.