• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • (Plesk for Windows):
    MySQL Connector/ODBC 3.51, 5.1, and 5.3 are no longer shipped with Plesk because they have reached end of life. MariaDB Connector/ODBC 64-bit 3.2.4 is now used instead.
  • 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.

Resolved Plesk Migrator Failing to Sync Database Records After Server Upgrade

Daerik

New Pleskian
Server operating system version
CentOS 7.9
Plesk version and microupdate number
18.0.64
I recently upgraded both the source and destination servers to MariaDB 11.4 and Plesk Obsidian 18.0.64. File sync works without issues, and the migrator is able to create database objects; however, the migration fails when syncing database records with the following error:

=|command: MYSQL_PWD="$(cat)" mysql --silent --skip-column-names -h localhost -P 3306 -u admin -e 'SELECT VERSION()'
=|exit code: 1
=|stdout:
=|stderr: mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
=|WARNING: option --ssl-verify-server-cert is disabled, because of an insecure passwordless login.
=|ERROR 1045 (28000): Access denied for user 'admin'@'127.0.0.1' (using password: YES)

Interestingly, when I manually cat the password file (/etc/psa/.psa.shadow) and run the command directly, it works fine:

MYSQL_PWD="$(cat /etc/psa/.psa.shadow)" mysql --silent --skip-column-names -h localhost -P 3306 -u admin -e 'SELECT VERSION()'

This indicates that the password file itself is not empty or invalid. However, the migrator seems to be having trouble retrieving or using it correctly during the sync process.

Is this a known issue with the Plesk Migrator in this setup, or is there a workaround to ensure the migrator uses the correct password when syncing databases?

As a potential workaround, should I attempt to manually sync the database files from /var/lib/mysql since the objects are already created, or is there a better solution for addressing the empty password file issue?

Any guidance or recommendations would be appreciated.
 
Looks like your issue might fall under this article: https://support.plesk.com/hc/en-us/...ss-denied-for-user-admin-1-using-password-YES

Give that a try and see if it helps you out.


You might also want to take a look at Question - Plesk Migrator Error: Access denied for user 'admin'@'127.0.0.1' (using password: YES)"
That solution worked. We had enabled skip-name-resolve to mitigate some aggressive crawls from AI think tanks on our real estate servers. Looks like this inadveterently prevented localhost to resolve to 127.0.0.1.
 
Good to hear that worked. Make sure to update the post to resolved if it's fully resolved o7
 
Good to hear that worked. Make sure to update the post to resolved if it's fully resolved o7
I've tried asking before on a proper way to mark my thread as resolved, however didn't get a response to that particular query. From what I had searched in the forum is that I don't have sufficient privledges to mark it as resolved myself. Is this something I could do myself or what is the process?
 
To edit the thread to mark it as resolved you click on the 3 dots and Edit Thread, then change the status. See screen shots below
1727869385841.png
1727869398489.png
 
Only the Guru's and the forum moderators can change the status of the posts to resolved.
 
1727871449553.png

--

On a side note, do I just ask in my threads for a guru to mark it as resolved or do I get a buddy that I can DM? :)
 
You don't have to, as soon as we see that someone replies with "It works", we mark it as resolved :)
 
Back
Top