Como resolver o erro er_password_no_match e loops de MySQL no cPanel

Quem gerencia servidores com cPanel sabe que o painel automatiza praticamente tudo no provisionamento de contas e no gerenciamento de senhas. Porém, quando um script interno entra em loop de erro, o diagnóstico pode ser um verdadeiro quebra-cabeça.

Recentemente enfrentei duas variantes desse mesmo problema: uma durante a criação de uma nova conta de usuário (usuario) e outra durante a alteração rotineira de senha de uma conta ativa (empresa). Em ambas as situações, o painel falhava ao tentar executar instruções no MySQL, gerando uma cascata contínua de exceções e travando a interface web com o seguinte erro:

Cpanel::Exception::Database::Error/(XID k3wmzt) The system received an error from the “MySQL” database “mysql”: ER_PASSWORD_NO_MATCH (Can't find any matching row in the user table)

Se você já encontrou falhas misteriosas de GRANT ou exceções no cpmysql.pl que impedem a associação de bancos ou travam a alteração de senhas no WHM, este passo a passo mostra as causas raízes nos bastidores, os becos sem saída com ferramentas descontinuadas e como resolver o problema via linha de comando ou pela interface gráfica.

1. O sintoma inicial no log de erros do cPanel#

O sinal de alerta apareceu ao monitorar o log principal do cPanel em tempo real:

tail -f /usr/local/cpanel/logs/error_log

O terminal registrou dois fluxos de execução problemáticos no subsistema Cpanel::Mysql:

Cenário a: falha na criação e provisionamento de bancos#

Cpanel::Mysql::Basic::_sendmysql_untrapped(Cpanel::Mysql=HASH(0x1b87070), "GRANT ALL ON `usuario\_base`.* TO 'usuario'\@'localhost'; "...) called at /usr/local/cpanel/Cpanel/Mysql/Create.pm line 237
Cpanel::Mysql::Create::__ANON__() called at /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/Try/Tiny.pm line 100
Try::Tiny::try(CODE(0x1e4bd78), Try::Tiny::Catch=REF(0x1d08cb8)) called at /usr/local/cpanel/Cpanel/Mysql/Create.pm line 241
Cpanel::Mysql::Create::_dbowner_to_all_without_ownership_checks(Cpanel::Mysql=HASH(0x1b87070), "method", "GRANT", "users", HASH(0x102ef50), "database", undef) called at /usr/local/cpanel/Cpanel/Mysql/Create.pm line 108
Cpanel::Mysql::dbcache(Cpanel::Mysql=HASH(0x1b87070), "") called at bin/admin/Cpanel/cpmysql.pl line 390

QUERY: GRANT ALL ON `usuario\_base`.* TO 'usuario'@'localhost'; GRANT USAGE ON *.* TO 'usuario'@'localhost'; GRANT ALL ON `usuario\_base`.* TO 'usuario'@'servidor.meudominio.com.br'; GRANT USAGE ON *.* TO 'usuario'@'servidor.meudominio.com.br'

Cenário b: falha durante alteração de senha da conta#

Cpanel::Mysql::Create::add_dbowner_to_all(Cpanel::Mysql=HASH(0x2fb77c0), "empresa", "SenhaTemporaria123", 0, undef, 1) called at /usr/local/cpanel/Cpanel/Mysql/Create.pm line 307
Cpanel::Mysql::Create::create_dbowner(Cpanel::Mysql=HASH(0x2fb77c0), "empresa", 1) called at bin/admin/Cpanel/cpmysql.pl line 169

QUERY: ALTER USER IF EXISTS 'empresa'@'localhost' IDENTIFIED BY 'SenhaTemporaria123'; GRANT USAGE ON *.* TO 'empresa'@'localhost'; ALTER USER IF EXISTS 'empresa'@'198.51.100.25' IDENTIFIED BY 'SenhaTemporaria123'; GRANT USAGE ON *.* TO 'empresa'@'198.51.100.25'; ALTER USER IF EXISTS 'empresa'@'servidor.meudominio.com.br' IDENTIFIED BY 'SenhaTemporaria123'; GRANT USAGE ON *.* TO 'empresa'@'servidor.meudominio.com.br'

O script em Perl cpmysql.pl falhava continuamente em ambos os fluxos ao tentar atualizar privilégios no MySQL.

2. A anatomia da falha: as duas causas do er_password_no_match#

A análise das queries enviadas pelo cPanel expõe a lógica interna do painel: ele tenta orquestrar a senha do sistema operacional replicando-a para o usuário do banco nos três escopos de rede utilizados pelo cPanel (localhost, o IP público do servidor e o FQDN completo da máquina).

O erro ER_PASSWORD_NO_MATCH (Can't find any matching row in the user table) tem duas origens técnicas distintas:

Causa 1: O usuário do banco de dados está fisicamente ausente#

Embora a query utilize ALTER USER IF EXISTS, certas versões do MySQL e MariaDB falham quando executam o comando seguinte (GRANT USAGE ON . TO 'empresa'@'...') em bloco dentro de uma transação DBI, se o usuário não constar previamente na tabela mysql.user.

O cPanel assume que o usuário dono da conta já existe no banco. Se a conta passou por migração imperfeita ou o usuário foi removido manualmente, a alteração de senha trava.

Causa 2: O usuário existe, mas o skip-name-resolve está ativo#

Este é o cenário mais enganoso. Você abre o console do MySQL, roda um SELECT User, Host FROM mysql.user e vê claramente o usuário cadastrado para servidor.meudominio.com.br. Mesmo assim, o MySQL devolve ER_PASSWORD_NO_MATCH.

Isso ocorre porque a diretiva skip-name-resolve no /etc/my.cnf desativa a resolução reversa de DNS. O motor do banco de dados ignora qualquer checagem baseada em nomes alfanuméricos de host, aceitando apenas IPs ou a palavra literal localhost. Quando o cPanel tenta rodar o comando apontando para o FQDN, o MySQL rejeita a instrução.

3. Comandos descontinuados e armadilhas comuns#

Ao tentar forçar o cPanel a reconstruir o mapa de privilégios de banco, é comum recorrer a scripts antigos documentados em fóruns. Em versões modernas do cPanel, a maioria desses scripts em Perl foi removida:

# /usr/local/cpanel/bin/restoreuserprivileges --user=usuario
-bash: /usr/local/cpanel/bin/restoreuserprivileges: No such file or directory

# /usr/local/cpanel/scripts/restorealluserprivileges
-bash: /usr/local/cpanel/scripts/restorealluserprivileges: No such file or directory

# /usr/local/cpanel/scripts/database_map_cleaner usuario
-bash: /usr/local/cpanel/scripts/database_map_cleaner: No such file or directory

Até mesmo chamadas via API de linha de comando (whmapi1 rebuild_dbmap) retornam Unknown app requested for this version of the API. As rotinas foram consolidadas nos daemons internos do painel.

4. Como resolver passo a passo#

Dependendo da causa identificada, a resolução segue por dois caminhos:

Solução para a Causa 1: Recriando o usuário ausente#

Se o usuário não constar na tabela mysql.user, você pode recriá-lo via terminal ou pela interface gráfica.

Opção a: via terminal (SSH)#

Acesse o console do MySQL como root:

mysql

Recrie o usuário para os três escopos identificados no log, utilizando a senha temporária capturada ou a nova senha definida:

CREATE USER 'empresa'@'localhost' IDENTIFIED BY 'MinhaSenhaSegura123!';
CREATE USER 'empresa'@'198.51.100.25' IDENTIFIED BY 'MinhaSenhaSegura123!';
CREATE USER 'empresa'@'servidor.meudominio.com.br' IDENTIFIED BY 'MinhaSenhaSegura123!';
GRANT USAGE ON *.* TO 'empresa'@'localhost';
GRANT USAGE ON *.* TO 'empresa'@'198.51.100.25';
GRANT USAGE ON *.* TO 'empresa'@'servidor.meudominio.com.br';
FLUSH PRIVILEGES;
EXIT;

Em seguida, execute a reconstrução do mapa de bancos da conta:

/usr/local/cpanel/scripts/rebuild_dbmap empresa

Opção b: pela interface gráfica (WHM/cPanel)#

Se você prefere operar pelo navegador:

1. No WHM, vá em SQL Services (Serviços SQL) e abra o Database Map Tool.
2. Selecione a conta em questão e verifique se as bases estão desvinculadas.
3. Acesse o cPanel da conta afetada, navegue até Bancos de Dados MySQL e recrie o usuário principal na seção "Usuários do MySQL".
4. Retorne ao WHM e refaça a alteração de senha da conta. O erro não ocorrerá mais, pois a tabela mysql.user agora possui o registro para o comando ALTER USER.

Solução para a Causa 2: Desativando o skip-name-resolve#

Se você confirmou que o usuário já existe na tabela mysql.user e o erro persiste teimosamente para o hostname FQDN, o culpado é o isolamento de DNS do MySQL.

Passo 1: Edite o /etc/my.cnf#

Abra a configuração do banco de dados:

sudo nano /etc/my.cnf

(Caso utilize arquivos modulares, verifique também /etc/my.cnf.d/).

Localize a diretiva e comente-a com #:

# skip-name-resolve

Salve o arquivo.

Passo 2: Reinicie os serviços#

Reinicie o banco de dados e o daemon do cPanel:

# Para sistemas com MariaDB:
sudo systemctl restart mariadb

# Para sistemas com MySQL 8.0+:
sudo systemctl restart mysqld

# Reiniciar o cPanel:
sudo systemctl restart cpanel

Validação e cuidados operacionais#

Assim que os serviços forem reiniciados com o usuário presente e o skip-name-resolve desativado, o arquivo /usr/local/cpanel/logs/error_log silenciará imediatamente. As queries de ALTER USER e GRANT passarão sem erros, destravando a alteração de senhas e a listagem de bancos de dados.

Alguns aprendizados práticos desse diagnóstico:

1. Otimizações genéricas de banco de dados podem quebrar painéis compartilhados: A diretiva skip-name-resolve é excelente em servidores isolados de aplicação, mas é incompatível com o modelo de privilégios baseado em FQDN do cPanel.
2. Cuidado ao copiar scripts antigos de fóruns: Comandos como restoreuserprivileges já não existem no cPanel atual. Analisar a query SQL bruta no log poupa horas de tentativas frustradas.
3. Mapeamento local no /etc/hosts: Para evitar lentidão em consultas de rede sem usar skip-name-resolve, certifique-se de que o FQDN da máquina (servidor.meudominio.com.br) esteja apontado para 127.0.0.1 dentro do arquivo /etc/hosts.

Veja também

Servidores Guia Completo de Zonas DNS no cPanel e WHM: Correção do Erro 'DNS Entry Already Exists', killdns e Templates Avançados

Servidores Troubleshooting cPanel: como tratei a tela branca ao acessar contas via WHM (xfercpanel)

Servidores Como renovei o certificado SSL expirado do hostname no cPanel/WHM (interface e terminal)

Este post está licenciado sob CC BY-NC.