Backups failing

17 posts / 0 new
Last post
#1 Thu, 06/25/2009 - 09:24

Backups failing

This just started happening during the nightly full backup:

mysqldump: Got error: 1045: Access denied for user 'xxxxxx'@'localhost' (using password: YES) when trying to connect

(username was omitted, of course ;-)

The username that it is trying to log in as is not root! Where is the username the backup uses stored?

The only thing I can think of that has changed is the upgrade of webmin and usermin. This may or may not be related. The backups were running fine, to the best of my knowledge. The last backups of the sites that have databases seem to coincide with the upgrade, but it took me a couple of days to notice tht not all of the backups were running correctly.

Thu, 06/25/2009 - 09:54

It may be using the user's account info to perform the backup -- is the MySQL password setup for that user correct? You can verify that in Edit Databases -> Passwords.

You may also want to try the password it's using on the command line by typing:

mysql -u username -p

And verify that you're able to get into MySQL

Thu, 06/25/2009 - 13:48 (Reply to #2)

The virtualmin virtual server backup utility is using the same wrong username every time to try to backup all of the databases on the server, as it encounters the databases during the individual virtual server backups. mysqldump is being given a user that is not root. I have cludged it so that it works; I changed the password on the login it is trying to use to match the root password, and the backups ran.

Thu, 06/25/2009 - 18:47 (Reply to #3)
Joe's picture

Database backups definitely should be happening as the virtual server user, and not root. However, if the MySQL password has been changed for the user outside of Virtualmin's control, it would fail.


Check out the forum guidelines!

Thu, 01/08/2015 - 05:55

Bumping an old thread as I am facing the same issue. 2 days ago I saw an update for virtualmin and webmin which I applied.

Yesterday I saw an update for wdm which I also applied.

The same night my backups started giving the above error for the sql dump. It goes without saying that since the night before they were always successful.

I tried to log in and the login is successful with the generated sql password for the user. I checked webmin and the privileges are in place, as they should, for each user and database.

What could cause this problem?

Thu, 01/08/2015 - 06:48

Hi, I'm facing same problem after last update of webmin to 4.13.gpl GPL. I'm able to backup database within Virtualmin -> Edit Databases -> Backup Database But server backups fail to complete with permission denied to domain user.

Thu, 01/08/2015 - 09:12

Same problem here. I checked permissions for the non root user and indeed there were no permissions granted to MySQL. So I gave this user full permissions and tried the virtualmin backup again and still failed with same error "Access denied". So restarted MySQL to make sure it had the recently granted permissions. Tried the virtualmin backup and still failing.

On a machine with virtualmin 4.13 but 32 bit CENTOS 6.5 instead of 64 bit CENTOS 6.5, the virtual server users do NOT have MySQL permissions (just like the failing machine was) and the daily backups on that machine complete successfully.

So it seems to be a problem with virtualmin 4.13 on a 64 bit CENTOS machine.

Thu, 01/08/2015 - 10:50 (Reply to #7)

Also, as a test, I created a new backup schedule from scratch and tried to run that. Got the same access denied error. So it's doesn't appear that the 4.13 upgrade changed something with the existing backup script since a brand new one also fails.

Thu, 01/08/2015 - 13:15

I'm also having this issue sine the last update. I can run mysqldump with the user and password in Virtualmin, but when the backup tries to run the same command, it fails, so I wonder if it's not getting the password to user properly for some reason for the actual backup procedure.

Thu, 01/08/2015 - 15:48
Kiekomick's picture

System Ubuntu Linux 12.04 64bit | MySQL Version 5.5.40 | Webmin Version 1.730 | Virtualmin Version 4.13

Same problems here, too. I checked all what my previous writer wrote and have every time the same issue. I made a backup over Virtualmin -> Edit Databases -> Backup Database -> fine!, I made a backup over Webmin -> MySql database server -> Backuptool -> absolute fine. But with the automatic Backup in Virtualmins [Backup and Restore] -> [Backup Virtualmin Servers] always failed. The issues starts after upgrade the new versions of virtualmin and webmin.

Thu, 01/08/2015 - 16:34

same problems here after virtualmin update...

mysqldump: Got error: 1045: Access denied for user 'aps24'@'localhost' (using password: YES) when trying to connect Backup failed! See the progress output above for the reason why.

Fri, 01/09/2015 - 02:48

I get the same MySQL 1045-errors during all backups on my server.

Fri, 01/09/2015 - 02:50

me, too!

Fri, 01/09/2015 - 03:10


There is another thread on this and there has been a workaround posted here:

I hope it helps.

(You need to create an account and be logged in to view the comment with the quick fix in it.)

Fri, 01/09/2015 - 03:45

Yes, thank you. The temp fix works, I am backing up as I write this..

Here it is for those that might end up here: For those who need a quick fix for this (which reverts Virtualmin to the old insecure behavior of writing backups with root permissions can do the following :

Edit the file /usr/{share,libexec}/webmin/virtual-server/

Change lines 947-948 to :

        local $err = &mysql::backup_database($db, $dbfile, 0, 1, undef,
                                     undef, undef, undef, undef, 1);

Run /etc/webmin/restart

Fri, 01/09/2015 - 12:17
Kiekomick's picture

Thanks both of you, tserts and mpattman. Now I can wait in rest for an official fix. For now I have for the time being my backups.

Mon, 01/12/2015 - 01:08

I started facing the same issue as soon as Virtualmin upgraded (4.13.gpl). After googling a bit I came to this thread.

Thanks to Tserts and Mpattman for the workaround, now backups work flawlessly.

Topic locked