Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I login with the root password on my box I can simply type

mysqldump --all-databases and I will get th expected "Dump".

I setup a job in cron.daily to run and dump this to a backup drive. The problem I have is that although the user is running as root I get the following message

mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: NO)

when trying to connect. I do not want to hard code the mysql database root password in the script (who would).

Considering that I can just type "mysqldump" at the command line in my bash shell there must be someway to get around using the -u parameter.I already have #!/bin/bash at the top of the script.

What am I missing here to get this to not ask for the root password to the database?

share|improve this question
up vote 12 down vote accepted

In order to connect to the mysql server you must provide credentials. You can specify them in a configuration file, pass them via the command line, or simply create account that doesn't require credentials.

Of course the no-password option should never be used, the pass-by command line isn't great because anyone who can run ps may be able to see the command line.

The recommended option is to create a mysql configuration file with the credentials in it and then protect that file with filesystem permissions so only your backup user can access it.

You being able to login to the mysql server while logged in interactively as root seems to suggest that you either don't have a root password set, or that you have a configuration file that is not being found by your script. If you have a .my.cnf you may need to manually point to it. If your root account doesn't have a password set then I would strongly encourage you to fix that.

Update (2016-06-29) If you are running mysql 5.6.6 or greater, you should look at the mysql_config_editor tool that allows you to store credentials in an encrypted file. Thanks to Giovanni for mentioning this to me.

share|improve this answer
That method still requires an unencrypted password in plain-text to be on the system. That is what i'm trying to avoid. – Mech Software Feb 8 '10 at 17:51
>you either don't have a root password set, or that you have a configuration file that is not being found by your script. Author clearly states that there is a mysql password for root, and that he is trying to access the database without supplying it to the mysqldump command: "(using password: NO)". Hence access denied error. – monomyth Feb 8 '10 at 17:53
@monomyth, the author also states that he can login without a password while interactively logged in as root. This tells me something is not right. – Zoredache Feb 8 '10 at 18:01
@Mech Software, There isn't much point of trying to protect yourself from the root account. If someone has the root account they could simply restart the mysql and bypass the permission system completely. – Zoredache Feb 8 '10 at 18:24
The reason I was able to login was the root account had a .my.cnf specified with 600 permissions, so thus that is how the shell was getting access. cron however, must be ignoring the file so I used the parameter in this post to point to it. – Mech Software Feb 8 '10 at 18:37

Security should not be done through obscurity. If you afraid that someone has access to your root account, it doesn't matter if root's mysql password is stored in the script, since you have all your data available in mysql dumps, or database files. So, the real question is what are you trying to protect?

If you don't want others to get a password that will let them change data in your database, you would need to create a user with appropriate permissions.

If you don't want that mysql password to be seen by any local account except root set file permissions on that script to be 0700 and owner to root.

share|improve this answer
I guess what I still don't understand is that If I can type (from the root prompt) mysqldump with no password input, why can't I run it through the cron job the same way. What piece is missing that requires the -p parameter. I'm not trying to "obscure" the password, I'd just rather never have it entered. Something particular to the root login itself is allowing the access, so why cant this be replicated with cron? – Mech Software Feb 8 '10 at 17:56
If you see that you can login without a password and with a password using the same "root" user, it is possible that there are multiple root users in your mysql database. Some of them might not have password set. You can remove password from the 'root'@'localhost' but then not only cron will be able to connect to your database, but anyone with a local account. This is not different (or worse) than having a password in a clear text script. – monomyth Feb 8 '10 at 18:04
I think the point is that MechSoftware was making is that being root essentially gives you read access to database files, and they are not encrypted. Therefore, requiring root MySQL password from the root user only to pretty print the data they essentially already can access is "security through obscurity". Besides, permissions are very easy to mess up, e.g. if someone is setting them recursively for a directory, if there's a symbolic link to the file etc. – Septagram May 14 '14 at 10:27

Your shell use can do it becuase you have a shell to run it from, ie when you logon, all your shell scripts in your profile get run.

Cron does not have such luxuries. When it logs on (as root) it'll log on with a default shell. This prevents anyone from logging on remotely, but it also means there is no auto-login scripts that are run.

You can set a shell for cron to run under, edit the crontab and add the SHELL and HOME variables, eg.


if these are not set, then cron will run with the shell and home directory specified in /etc/passwd (which are probably nothing, possibly /bin/sh).

If you want to see the environment cron is running as, add a cron job that exports env to a file, eg:

$crontab -e
* * * * * env > /tmp/crontabenv.log
share|improve this answer

If the script is run by root you could create a file /root/.my.cnf with permissions 600 and the following contents:

password = DBPASSWORD

(where you enter your MySQL username and password of course).

This file will automatically be read by any mysql command-line tool, if it is run as root. No more need to provide it on the command-linea. The 600 permissions protect it against prying eyes.

share|improve this answer
I found this was the case of HOW I was able to us mysqldump without the password. So this solved the mystery of how the SHELL is doing it, so why is cron not reading it? – Mech Software Feb 8 '10 at 18:32
mysqldump when run from cron may not be able to locate the .my.cnf file. The remedy is to add a mysqldump parameter to explicitly read the options in file, i.e. --defaults-extra-file=/root/.my.cnf I learned this from two other answers on Stack Overflow. See and – MikeOnline Dec 16 '15 at 19:50

Cron can be very frustrating to debug. When the cron jobs execute, they don't have an environment set like you take for granted with a shell.

Tips for cron:

  • use full paths to everything -- "ECHO=/bin/echo", etc: (define variables at the top to make it easier)
  • set MAILTO, so you get an email from each job (or have the jobs redirect stderr/stdout to a file)

If your root user can do it from the shell, cron should be able to do it. Make sure you explicitly specify the config file to use on the command-line.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.