• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved SQLSTATE[HY000] [1045] Access denied for user 'es_fprkmvi'@'localhost' (using password: YES)

ynb.dev002

New Pleskian
Server operating system version
Ubuntu 22.04.3 LTS
Plesk version and microupdate number
Plesk Obsidian Web Pro Edition Version 18.0.54 Update #4
Hi,

I'm encountering this error: "SQLSTATE[HY000] [1045] Access denied for user 'es_fprkmvi'@'localhost' (using password: YES)" on all domains whenever I navigate to any domain -> Mail -> Email Config Check.

The issue is that the user 'es_fprkmvi'@'localhost' doesn't exist.
This is on an on-line server.

I created the user in Plesk and the MySQL database, granted all privileges for all databases, but nothing changed.

If I edit the file /etc/mysql/my.cnf and add the line "skip-grant-tables," the error disappears. However, since this creates a security breach and disables external connections to the database, I can't use it as a permanent solution.

I suspect the user 'es_fprkmvi'@'localhost' came from a server backup that was restored here.

I'm hoping you can assist me with this.

Best regards, Carlos Matos
 

Attachments

  • Print Screen 2023-08-25 111752.jpg
    Print Screen 2023-08-25 111752.jpg
    99.8 KB · Views: 8
Did you restore to a newer database version? Which database version are you using and what is the current content of /etc/my.cnf? I am asking as the issue is probably caused by the "@localhost" compared to "@127.0.0.1". The database server does not resolve the "localhost" to the IP address or the bind statement in the my.cnf configuration tells the server to only listen to one specific IP. There have recently been threads on here discussing similar issues and the solution was to remove the "bind-address" from my.cnf file completely. Else, if you bind to one specific address, the permission entries in the user table of the database must also use that one address. In that case localhost is different from 127.0.0.1, because these are compared as strings.
 
Did you restore to a newer database version? Which database version are you using and what is the current content of /etc/my.cnf? I am asking as the issue is probably caused by the "@localhost" compared to "@127.0.0.1". The database server does not resolve the "localhost" to the IP address or the bind statement in the my.cnf configuration tells the server to only listen to one specific IP. There have recently been threads on here discussing similar issues and the solution was to remove the "bind-address" from my.cnf file completely. Else, if you bind to one specific address, the permission entries in the user table of the database must also use that one address. In that case localhost is different from 127.0.0.1, because these are compared as strings.

Hi, Peter

Yes I restored for a newer version. I'm using MariaDB 10.6.15 and the server is listening to all IP connections.

Best regards, Carlos Matos
 
If you still have the formerly working "bind-address = ::" in your my.cnf, please remove that line, then restart the database server. Because starting from 10.6 if the line exists, MariaDB binds only to the mentioned addresss.
 
If you still have the formerly working "bind-address = ::" in your my.cnf, please remove that line, then restart the database server. Because starting from 10.6 if the line exists, MariaDB binds only to the mentioned addresss.
Hi, Peter

I don't have that line in my.conf

Best regards, Carlos Matos
 
That prefix (es_) does belong to Email Security. For example, you can use the next query in plesk db to find credentials used by ES:
Code:
select ms.name,ms.value from ModuleSettings ms
join Modules m
where m.id=ms.module_id
and m.name='email-security';

Once these are at hand, recreate this user in MySQL. As for the cause, looks like the mysql db was restored, hence user went missing.
 
That prefix (es_) does belong to Email Security. For example, you can use the next query in plesk db to find credentials used by ES:
Code:
select ms.name,ms.value from ModuleSettings ms
join Modules m
where m.id=ms.module_id
and m.name='email-security';

Once these are at hand, recreate this user in MySQL. As for the cause, looks like the mysql db was restored, hence user went missing.
Hi, Strangelove

ModuleSettings don't exist.

Best regards, Carlos Matos
 
Hi, Strangelove

The user exists on psa.

What I need to do now?

Best regards,
Carlos Matos

Recreate the user. Then grant it with privileges on the `emailsecurity` DB.

Code:
CREATE USER 'XXXXXXX'@'localhost' IDENTIFIED BY 'XXXXXXXXXXXX';
GRANT SELECT, INSERT, UPDATE, DELETE on emailsecurity.* to 'XXXXXXXXXX'@'localhost';

XXXXXXXXX's are to be replaced with the username(it starts with es_) and password from ModuleSettings
 
Recreate the user. Then grant it with privileges on the `emailsecurity` DB.

Code:
CREATE USER 'XXXXXXX'@'localhost' IDENTIFIED BY 'XXXXXXXXXXXX';
GRANT SELECT, INSERT, UPDATE, DELETE on emailsecurity.* to 'XXXXXXXXXX'@'localhost';

XXXXXXXXX's are to be replaced with the username(it starts with es_) and password from ModuleSettings
Hi, Strangelove

It worked :D!
Thanks for your help.

Best regards,
Carlos Matos
 
Back
Top