mysqldump "error 1045 access denied" during backup

Not specified by the original author.

TL;DR

Test a plain mysql login with the exact user, host and socket the dump job uses; error 1045 means that account entry is not matching or its stored credential is stale. Fix the defaults file the job reads or the grant for that user and host combination, confirm the backup privileges, then rerun the dump. Do not assume the interactive root login proves the backup account works.

mysqldump "error 1045 access denied" during backup

Use this when

• mysqldump reports error 1045 access denied for a named user and host.
• The dump broke after a credential rotation, a server migration or a MySQL upgrade.
• Manual dumps work but the scheduled backup fails with 1045, or the reverse.

Not for this skill when

• mysqldump loses the connection mid dump with error 2013. That points at timeouts and server limits, not authentication.
• The account logs in but cannot read a specific table. That is a privilege scope problem after authentication, handled differently.
• The server is unreachable on the network. Fix routing, firewall or the listener first.

Steps

1. Copy the exact mysqldump invocation from the job, including its defaults file, host, port and socket options, and run a simple mysql connection test with the same options and the same operating system user. Note the full user and host shown in the 1045 message, because MySQL matches accounts by both parts. Verify: the connection test reproduces 1045 with the job options, or succeeds and shows the job environment differs from your shell
2. Inspect the defaults file and option files the job reads for an old account entry, an extra defaults file earlier in the search order overriding the intended one, or a credential left from before a rotation. Correct the file the job actually reads rather than editing a different option file that only your shell uses. Verify: the option files in the job search order contain one consistent backup account and the connection test now reaches an authentication decision from the server
3. On the server, list the account entries for that user across hosts and check which one matches the connection source, including socket connections that match a loopback or socket specific entry. Reset the credential for the matching entry through your approved process and record the change in the rotation log without writing the value into the backup script. Verify: the server shows a single intended account entry for the backup source and a fresh connection test with the job options logs in successfully
4. Verify the backup account holds the privileges mysqldump needs for your options, typically SELECT, LOCK TABLES where locking is used, SHOW VIEW, TRIGGER, EVENT and RELOAD or PROCESS for single transaction workflows on newer versions. Add only the missing grants for the databases in scope. Verify: a show grants review covers every option in the dump command and a test dump of a small database completes
5. Run the full dump for the smallest production database first, watch it pass authentication and table reads, then run the real job. If 1045 returns only for one database, recheck grants and account entries specific to that scope instead of rotating credentials again. Verify: the scheduled job completes, the dump file size is in the expected range, and the completion check in your backup log shows status zero
6. Remove stale backup accounts and old option files left by the rotation, and document which defaults file and account the job depends on. Schedule a reminder to test the login before the next rotation takes effect. Verify: only the intended backup account remains, the runbook names its defaults file, and a pre rotation login test is on the checklist

Why it happens

MySQL authentication matches on user plus host, and mysqldump reads credentials from option files whose search order depends on the operating system user and the defaults file flags in the job. A rotation that updates one file, or a grant created for a host entry the connection never matches, leaves the job presenting an old or unmatched credential while interactive logins keep working. Upgrades add another wrinkle when authentication plugins change and older clients or accounts negotiate differently. Error 1045 is precise evidence: the server was reached and rejected the presented identity, so network theories should be dropped until the exact job login succeeds.

Variants and edge cases

Anonymous user entries can shadow a named account for socket connections on some installs, producing 1045 even with a correct credential for the named account. If the matching logic looks right and login still fails locally, check for anonymous entries. Also beware cron and systemd environments: they may run with a different home directory, so the option file your shell reads is not the one the job reads.

mysqldump error 1045 access denied for user backup at host

The named account variant. Work the user and host pair exactly as printed, including whether the connection came over a socket or TCP.

mysqldump works manually but cron backup gets 1045

The environment variant. The job reads a different defaults file or home directory; prove it by running the connection test under the job scheduler context.

mysqldump 1045 after password rotation

The rotation variant. One copy of the credential was updated and another was not; find every option file and vault entry the job can read and align them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiVjIPImaisyXfdXlrm-Mw

Resolved from the public thread: https://vectle.com/posts/pstiVjIPImaisyXfdXlrm-Mw

Thread query: mysqldump "error 1045 access denied" during backup

TL;DR: Test a plain mysql login with the exact user, host and socket the dump job uses; error 1045 means that account entry is not matching or its stored credential is stale. Fix the defaults file the job reads or the grant for that user and host combination, confirm the backup privileges, then rerun the dump. Do not assume the interactive root login proves the backup account works.