These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for MySQL Dump Failed, Access Denied on the new forum.
I posted this on the recent failed backup thread over here: http://virtualmin.com/node/35764#comment-142515
I have upgraded to the latest 4.13-2 release and yet my MySQL backups are failing.
The error is
Dumping MySQL database db_prod1 .. .. dump failed! mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: YES) when trying to connect
It was suggested I check to make sure the MySQL root password was the same, and I reset it then changed it in MySQL Module config. I ran a backup and the error still persists.
Howdy,
At first glance, it sounds like Virtualmin isn't seeing or using your correct MySQL password for some reason. I suspect it's not just an issue with backups, but we'll have to test that to be sure.
First off, if you go into System Settings -> Re-Check Config, does that detect any problems?
If not, are you able to create a new Virtual Server that has the "MySQL Database" feature enabled?
-Eric
There are no issues reported within the Re-Check Config. And I was able to create a new Virtual Server with the MySQL Database feature enabled.
I've also been noticing failures myself going back about 5 or so days. I do nightly backups and so far the only thing failing is the mysql dump. I've gone through a system settings ->re-check as well and everything looks good.
tmiller91, Jamie was wondering if you had a "pass=" line set in your Webmin config.
You can determine that by running this command:
grep pass= /etc/webmin/mysql/config
You don't need to tell us what it is, just let us know if the above command shows us your root MySQL password.
-Eric
Hello Eric,
Yes, there is a pass= with the password in that file. I checked and it is the same password that I reset the MySQL module to yesterday.
Thanks for that info!
I'm doing some testing, as well as relaying that information to Jamie, to try and figure out what might be causing the problem you're seeing.
We'll get back with you once we have some more information.
-Eric
Do you happen to have a .my.cnf file in the domain's homedir, or in root's homedir?
Some testing revealed that can cause the problem you're seeing.
-Eric
Wow, that resolved it. That's weird though. The file was last edited early on in 2014 so it might have been apart of my cPanel migrations in 2014. But the file has definitely been in that director for quite a bit of time, several months.
Either way, that resolved it for me. Thanks so much for all your hard work guys.
I can confirm I had a .my.cnf file in my virtual server home directory and removing it cured the problems, I am now able to dump database. The file was probably a hangover from my cPanel days.
Seems that Eric ID'd the problem.
Howdy,
I'm glad that helped!
The issue came up now due to a change in the way Virtualmin handles backups... it's seeking to be more secure, and moving more towards running as much as it can as the Virtual Server owner, rather than root.
In doing so, it's inadvertently pulling the settings from the .my.cnf file located in the Virtual Server owner's home directory.
I believe Jamie is working on preventing that behavior for a future release, removing the .my.cnf file is just a temporary thing until Jamie comes up with a better long-term solution (ie, getting Virtualmin/MySQL to ignore that file during the backup process if it exists).
-Eric
I have 50 + sites that all uses the .my.cnf that I am unable to backup off. Is there anyway to roll back to 4.12 as it did not seem to have the problem or is there an ETA on the fix?. All our sites depend on the .my.cnf.
Why don't you just delete the .my.cnf files? I'm assuming you're an ex cPanel customer and they are a leftover of that. If so, why do you need them now?
Are those.my.cnf files even needed in Virtualmin virtual server home directories?
All our applications actually needs this file. This is the way we alway configure mysql information. So that is not an option.
Sune
Howdy,
Talking to Jamie, it sounds like this is an issue with the current Webmin version.
The next Webmin version will correct it; alternatively, he has released an update to the Webmin MySQL module which fixes the problem:
http://www.webmin.com/updates.html
I just upload and install it via, webmin modules right? if that is the case it did not change anything.
Sune