Corrigindo o Erro “SET PASSWORD Has No Significance for User root@localhost” no MySQL

O erro "SET PASSWORD has no significance for user 'root'@'localhost'" ocorre no MySQL quando o servidor recusa processar um comando SET PASSWORD para a conta root — normalmente porque o utilizador root é autenticado através do plugin auth_socket ou unix_socket em vez de um método tradicional baseado em palavra-passe. Nestas configurações, o MySQL delega a autenticação ao sistema operativo, tornando as alterações de credenciais baseadas em palavra-passe sem sentido ao nível SQL.

Este guia abrange todas as causas raiz, a sequência de diagnóstico correta e múltiplos caminhos de resolução — incluindo casos extremos que surgem em ambientes VPS geridos, servidores baseados em cPanel e sistemas de produção reforçados.

Por Que Este Erro Ocorre: Análise da Causa Raiz

Compreender o gatilho exato é essencial antes de aplicar qualquer correção. O erro não é uma falha de permissões no sentido tradicional — é um sinal de que a camada de autenticação do MySQL é completamente ignorada para a conta root.

O Plugin auth_socket / unix_socket

Nos sistemas modernos Debian, Ubuntu e seus derivados, o MySQL (e MariaDB) configura o utilizador root para autenticar através do plugin auth_socket por padrão. Quando este plugin está ativo, o MySQL verifica a identidade do utilizador do SO que se conecta em vez de verificar uma palavra-passe. Consequentemente, qualquer tentativa de definir uma palavra-passe usando SET PASSWORD é rejeitada — o servidor considera o comando irrelevante para esse modelo de autenticação.

Pode verificar isto imediatamente após iniciar sessão:

SELECT user, host, plugin, authentication_string
FROM mysql.user
WHERE user = 'root' AND host = 'localhost';

Se a coluna plugin retornar auth_socket (MySQL) ou unix_socket (MariaDB), esta é a sua causa raiz.

Outros Fatores Contribuintes

• Privilégios insuficientes: O utilizador em execução não possui privilégios SUPER ou SYSTEM_USER necessários para modificar as credenciais do root.
• Diretivas restritivas my.cnf / my.ini: Opções como skip-grant-tables ou políticas personalizadas de validate_password podem interferir com operações de palavra-passe.
• Incompatibilidade de versão do MySQL: A sintaxe SET PASSWORD foi descontinuada no MySQL 8.0 e removida de determinados contextos. O método preferido é ALTER USER.
• Tabelas de sistema somente leitura: Em algumas implementações em nuvem ou em contentores, o esquema de sistema mysql pode estar parcialmente bloqueado.

Comparação: SET PASSWORD vs. ALTER USER vs. UPDATE

Estes três métodos não são intercambiáveis. Escolher o errado para a sua versão do MySQL ou plugin de autenticação irá produzir o erro em questão ou falhar silenciosamente.

Resolução Passo a Passo

Passo 1: Iniciar Sessão no MySQL como Root

Em sistemas que utilizam auth_socket, deve iniciar sessão como utilizador root do SO — não aparecerá nenhum pedido de palavra-passe:

sudo mysql -u root

Se o seu sistema utiliza autenticação por palavra-passe e conhece a palavra-passe atual:

mysql -u root -p

Passo 2: Confirmar o Plugin de Autenticação

Execute a consulta de diagnóstico:

SELECT user, host, plugin, authentication_string
FROM mysql.user
WHERE user = 'root';

Tome nota do valor na coluna plugin antes de prosseguir. Isto determina qual correção se aplica à sua situação.

Passo 3: Verificar os Privilégios Atuais

Antes de modificar a autenticação, confirme o conjunto de concessões da conta root:

SHOW GRANTS FOR 'root'@'localhost';

O resultado deve incluir GRANT ALL PRIVILEGES ON *.* ... WITH GRANT OPTION. Se não incluir, provavelmente está conectado como um utilizador com direitos insuficientes — autentique-se novamente usando sudo mysql para invocar a confiança ao nível do SO.

Passo 4: Mudar para Autenticação por Palavra-Passe e Definir uma Nova Palavra-Passe

Esta é a correção principal quando auth_socket ou unix_socket é o plugin ativo. A instrução ALTER USER altera simultaneamente o plugin de autenticação e define a palavra-passe numa única operação atómica:

ALTER USER 'root'@'localhost'
  IDENTIFIED WITH mysql_native_password
  BY 'YourStrongPassword!9#';

FLUSH PRIVILEGES;

Para MariaDB, o equivalente é:

ALTER USER 'root'@'localhost'
  IDENTIFIED VIA mysql_native_password
  USING PASSWORD('YourStrongPassword!9#');

FLUSH PRIVILEGES;

> Nota de segurança: No MySQL 8.0.34 e posterior, mysql_native_password está descontinuado em favor de caching_sha2_password. Para sistemas de produção, utilize:

>

> “`sql

> ALTER USER 'root'@'localhost'

> IDENTIFIED WITH caching_sha2_password

> BY 'YourStrongPassword!9#';

> “`

Passo 5: Conceder Privilégios Completos (Se Necessário)

Se a verificação de privilégios no Passo 3 revelou concessões incompletas, restaure-as explicitamente:

GRANT ALL PRIVILEGES ON *.*
  TO 'root'@'localhost'
  WITH GRANT OPTION;

FLUSH PRIVILEGES;

Não utilize a sintaxe legada GRANT ... IDENTIFIED BY no MySQL 8.0+. Essa sintaxe combinada foi removida. Separe sempre as instruções GRANT e ALTER USER.

Passo 6: Verificar a Correção

Confirme que o plugin foi atualizado:

SELECT user, host, plugin FROM mysql.user WHERE user = 'root';

Saia do MySQL e reconecte usando a nova palavra-passe para validar de ponta a ponta:

mysql -u root -p

Método de Emergência: Redefinição via skip-grant-tables

Se estiver completamente bloqueado e não conseguir autenticar, utilize o modo skip-grant-tables. Isto ignora todas as verificações de privilégios e deve ser utilizado apenas numa janela de manutenção controlada e offline.

1. Parar o serviço MySQL:

sudo systemctl stop mysql
# or for MariaDB:
sudo systemctl stop mariadb

2. Iniciar o MySQL com as tabelas de concessão desativadas:

sudo mysqld_safe --skip-grant-tables --skip-networking &

O sinalizador --skip-networking é crítico — impede quaisquer ligações remotas durante este estado inseguro.

3. Conectar sem credenciais:

mysql -u root

4. Atualizar os privilégios e depois atualizar a palavra-passe:

FLUSH PRIVILEGES;

ALTER USER 'root'@'localhost'
  IDENTIFIED WITH mysql_native_password
  BY 'YourStrongPassword!9#';

FLUSH PRIVILEGES;

5. Reiniciar o MySQL normalmente:

sudo systemctl restart mysql

Verificar e Ajustar os Ficheiros de Configuração do MySQL

O ficheiro my.cnf (Linux) ou my.ini (Windows) pode conter diretivas que interferem com operações de palavra-passe. Localizações comuns:

• /etc/mysql/my.cnf
• /etc/my.cnf
• /etc/mysql/mysql.conf.d/mysqld.cnf

Verifique estas diretivas problemáticas na secção [mysqld]:

skip-grant-tables       # Disables all privilege enforcement — remove after recovery
validate_password       # May reject passwords that don't meet complexity rules
bind-address            # Affects remote access, not password changes directly

Se validate_password estiver a aplicar uma política que rejeita a palavra-passe escolhida, cumpra os requisitos da política ou ajuste temporariamente o nível da política:

SET GLOBAL validate_password.policy = LOW;
SET GLOBAL validate_password.length = 8;

Considerações Específicas por Plataforma

Ambientes cPanel e WHM

Em instalações de VPS com cPanel, as credenciais root do MySQL são geridas pelo próprio cPanel. Alterar manualmente a palavra-passe root fora do WHM pode quebrar as ligações internas de base de dados do cPanel. Utilize sempre WHM > SQL Services > Change MySQL Root Password para estes ambientes. Se tiver de utilizar a CLI, execute /usr/local/cpanel/scripts/mysqlpasswd posteriormente para ressincronizar as credenciais armazenadas do cPanel.

Ambientes VPS Geridos

Num ambiente de VPS Hosting onde tem acesso root completo ao SO, a abordagem sudo mysql (aproveitando auth_socket) é o ponto de entrada mais fiável. Evite desativar auth_socket a menos que a sua pilha de aplicações requeira especificamente autenticação root baseada em palavra-passe — a autenticação ao nível do SO é arquiteturalmente mais segura.

Servidores Dedicados

Em Servidores Dedicados com configurações MySQL reforçadas, o plugin validate_password é frequentemente ativado com aplicação de política STRONG. Certifique-se de que a sua palavra-passe de substituição cumpre os requisitos mínimos: pelo menos 8 caracteres, maiúsculas e minúsculas, dígitos e caracteres especiais. Pode verificar as definições de política atuais com:

SHOW VARIABLES LIKE 'validate_password%';

Melhores Práticas de Segurança Após Resolver o Erro

Assim que o problema da palavra-passe root estiver resolvido, aplique imediatamente estes passos de reforço:

• Execute mysql_secure_installation para remover utilizadores anónimos, bases de dados de teste e login root remoto.
• Desative o login root remoto: Certifique-se de que não existe nenhuma entrada 'root'@'%' em mysql.user.
• Crie utilizadores específicos para aplicações com os privilégios mínimos necessários em vez de utilizar root para ligações de aplicações.
• Rotacione as credenciais armazenadas nos ficheiros de configuração de aplicações (.env, wp-config.php, database.yml) para corresponder à nova palavra-passe.
• Ative SSL/TLS para ligações MySQL — particularmente relevante se o seu servidor de aplicações e servidor de base de dados estiverem em hosts separados. Combine isto com um Certificado SSL válido na sua camada web.
• Audite a tabela mysql.user periodicamente para identificar contas com valores authentication_string vazios ou wildcards de host excessivamente amplos.

Lista de Verificação de Pontos-Chave Técnicos

Utilize isto como uma matriz de decisão rápida quando encontrar este erro:

• Verifique o plugin primeiro — execute SELECT plugin FROM mysql.user WHERE user='root' antes de tentar qualquer correção.
• Utilize ALTER USER, não SET PASSWORD — SET PASSWORD está descontinuado no MySQL 8.0+ e é incompatível com autenticação baseada em socket.
• Utilize sempre sudo mysql em sistemas Ubuntu/Debian — a confiança ao nível do SO ignora o plugin socket sem o desativar.
• Nunca deixe skip-grant-tables ativo em produção — remove todo o controlo de acesso do seu servidor de base de dados.
• Separe GRANT de ALTER USER no MySQL 8.0+ — a sintaxe combinada GRANT ... IDENTIFIED BY já não existe.
• Em servidores cPanel, utilize o WHM ou o script de ressincronização do cPanel — alterações diretas na CLI irão quebrar as sessões internas de base de dados do cPanel.
• Valide a correção de ponta a ponta — reconecte com mysql -u root -p após cada alteração para confirmar que as novas credenciais funcionam antes de fechar a sessão.
• Reveja my.cnf para diretivas validate_password se ALTER USER for bem-sucedido mas a palavra-passe for rejeitada.

Perguntas Frequentes

Por que SET PASSWORD funciona em alguns servidores mas não noutros?

O comportamento depende do plugin de autenticação atribuído à conta root. Em servidores que utilizam mysql_native_password ou caching_sha2_password, SET PASSWORD pode ainda funcionar no MySQL 5.7. Em sistemas Ubuntu/Debian onde auth_socket é o padrão, o comando é rejeitado porque nenhuma palavra-passe é armazenada ou verificada. O MySQL 8.0 descontinuou ainda mais SET PASSWORD, tornando ALTER USER o único método fiável entre versões.

Posso reativar auth_socket após mudar para autenticação por palavra-passe?

Sim. Execute ALTER USER 'root'@'localhost' IDENTIFIED WITH auth_socket; e depois FLUSH PRIVILEGES;. Após isto, sudo mysql funcionará novamente sem palavra-passe, e mysql -u root -p falhará. Esta é a configuração recomendada para sistemas onde apenas é necessário acesso root autenticado pelo SO localmente.

Qual é a diferença entre FLUSH PRIVILEGES e reiniciar o MySQL?

FLUSH PRIVILEGES recarrega as tabelas de concessão do disco para a memória sem reiniciar o serviço. É suficiente após modificações diretas em UPDATE mysql.user. As instruções ALTER USER e GRANT escrevem diretamente nas tabelas de concessão e têm efeito imediato — FLUSH PRIVILEGES é tecnicamente redundante após elas, mas inofensivo e amplamente utilizado como medida de segurança.

Por que GRANT ALL PRIVILEGES ... IDENTIFIED BY falha no MySQL 8.0?

O MySQL 8.0 removeu a capacidade de criar ou modificar utilizadores implicitamente dentro de uma instrução GRANT. A cláusula IDENTIFIED BY em GRANT foi descontinuada no MySQL 5.7 e removida no 8.0. Deve utilizar CREATE USER ou ALTER USER separadamente e depois emitir a instrução GRANT sem a cláusula IDENTIFIED BY.

É seguro executar uma base de dados MySQL num plano de alojamento partilhado?

Para projetos pessoais de baixo tráfego, o Alojamento Web Partilhado com MySQL gerido é adequado. No entanto, não terá acesso direto a mysql.user, gestão de GRANT ou ficheiros de configuração. Para qualquer carga de trabalho que requeira controlo administrativo direto sobre o MySQL — incluindo a resolução de erros como este — um ambiente de VPS Hosting com acesso root ao SO é a escolha adequada.