Error in Backup and Restore

OS type and version Ubuntu 22.04
Webmin version Latest
Virtualmin version Latest

Im using the option Backup and restore to move virtual servers from a VPS with Ubuntu 20.04 to another one with 22.04, both have the latest Virtualmin installed all uptodate.
I got this error when I run the Restore process in the Ubuntu 22.04 VPS:

Restore failed : SQL create user ''@'localhost' identified by password '$A$005$0#,MPmlc)''1l{fU9/JqSvlpjL.uP/76oh1uf/vhSfOmGaQ/oNWFNVgcGFA' failed : Password hash should be a 41-digit hexadecimal number

I tried changing password, using only numbers and nothing, any idea?
Happy New Year!

are both systems using the same database type, like MYSQL or MariaDB?

Are both systems using the same setting for storing passwords (hashed / plaintext)? You choose this in the post-install wizard.

No, VPS old use MySQL, new one MariaDB

I don’t remember that, how can I check it?
The old VPS have 10 Wordpress sites, I already migrated 6 of them with zero issues, the last 4 are giving me this error.

If you have different database servers on the two VPS’ then @stefan1959 has put you on the right track to troubleshoot the issue. The password hash is not important under the circumstances.

If that’s true, why 6 others websites using databases all have zero issues during the restoration process?

Any idea where I have to look at?

Well, you could look at the incompatibilities between the versions of the two database servers in the context of the features of the database that your app uses - I mean the app on the domains / virtual servers which you are unable to restore successfully.

Those apps which make use of any feature in the database which is not compatible with the database server on which you are restoring the database, will cause you to see an error.

All the 10 sites are just simple Wordpress blogs, almost all of them have the same plugins. There’s no logic in 6 of them been restored fine and 4 give me errors.

But the error is a Database error, searching I found the same old bug in Virtualmin, could be the same issue? Some Admin here?

When referring to old topics you’ve found, please link it, so we know what you’re talking about. If it was a bug, and old, it’s very unlikely to be the same thing (we fix bugs, when identified and reproducible).

Hello Joe and thanks for take the time to answer me!
I found these reports just because is the same error message but in my case the error show me in the middle of Restoration process in the new server. I can read the bugs were fixed.

Im attaching the module config screen for the new server, it’s the same in the old one with MySQL.

This is the first error message:

Restore failed : SQL create user ''@'localhost' identified by password '$A$005$j7/&' failed : Password hash should be a 41-digit hexadecimal number

after read the second bug report I try changing the mysql user password to 41 only numbers and I got this error:

Restore failed : SQL create user ''@'localhost' identified by password '$A$005$/%V4Hx7gR4-NSD~=HElvpp0gD9RakRn3pfKy97GPa1xKm23urQf4i0GhRQg/' failed : Password hash should be a 41-digit hexadecimal number

If you need more info just let me know.

So, the actual password is irrelevant. This error is always about the hashed password (which is not the password, but the hash that is generated from the password).

I’m guessing the issue is somehow related to going from MySQL (the old default database on Ubuntu with Virtualmin installed with the version 6 installer) to MariaDB (the new default database on Ubuntu when installed with the version 7 installer). This is a guess, but I don’t have a better one at the moment.

It is surprising that some of your databases succeeded, though, since they’re also going from MySQL to MariaDB (I assume).

I’ll ask @Jamie if he has any idea about this, since those old issues were similar, and seem likely to be related (but not the same, obviously, since they were fixed).

1 Like


I have faced the exact same issue few days back. In my case, although the error is same, issue happens when restoring ‘mail and ftp users’ [MFU henceforth]. So the error looks like comes from database users but actually comes from MFU . I was able to successfully restore my virtual servers to new server when 'MFU ’ option was unselected.

I still have not found an easy way to transfer MFU. If anyone has got an idea please let me know. Or else all users have to be manually re-created which is a pain.

Vishnu N

Yes I have the issue in the exact same phase of the Restoration process.
Sorry @vishnunn what is MFU?

As he said in his message MFU = mail & ftp users.

1 Like

Oh! That does put a new spin on the problem, and I see now that in fact we are talking about a mail/FTP user (`‘user@domain’@‘localhost’). I guess this user has been granted access to databases? That’s somewhat unusual, and probably explains why some domains succeeded and others failed.

Am I correct in guessing that the domains that succeeded did not have any email/FTP users that had been given database access?

YES!! Domains that have an extra user with only access to the DB are the ones that throw me an error.

User with the error have this access:
Login Access == Email only
Databases== Yes

What is the exact Virtualmin and Webmin version do you have installed?

In both VPS:
Webmin version 2.001
Virtualmin version 7.3-1

I have taken a deeper look into this problem, and this failure is expected and the best thing we can (and must) do is to work around the problem for Mail and FTP users, which have access to the databases.

It happens because of MySQL and MariaDB have different password plugins, which result into a different password hashing format for database user. This can be checked by logging in as root to MySQL/MariaDB server and running SELECT plugin FROM mysql.user;.

Restore failed : SQL create user ‘’@‘localhost’ identified by password ‘$A$005$0#,MPmlc)’‘1l{fU9/JqSvlpjL.uP/76oh1uf/vhSfOmGaQ/oNWFNVgcGFA’ failed : Password hash should be a 41-digit hexadecimal number

@Jamie, we really should make sure that it does’t cause a fatal failure upon the restore, and that it just throws a warning (i.e. instead of failing fatally or typing ..done as in case of success, we should type ..warning : user was restored but access to the database cannot be granted automatically), mentioning that it should be done manually after the restore by providing the actual password on Edit Users: Edit User page.