Fix MySQL Error 1045: Access Denied for User

1. Wrong Password (most common)

You're typing the right username but the password is wrong. MySQL error 1045 will hit you immediately when the password mismatch happens. The server doesn't tell you which part is wrong — just that access is denied.

The fix: Reset the password using the MySQL root account. If you can't log in as root either, skip to section 2.

mysql -u root -p

Once in, run:

ALTER USER 'youruser'@'localhost' IDENTIFIED BY 'newpassword';
FLUSH PRIVILEGES;

If you're on MySQL 8.0+, the default authentication plugin is caching_sha2_password. Some old PHP clients can't handle that. In that case, force the old plugin:

ALTER USER 'youruser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'newpassword';

What's happening here is the authentication plugin mismatch — the client sends a hash the server can't verify. Switching to mysql_native_password fixes it for legacy apps.

2. User Doesn't Have Access from Your Host

You might have the right password but MySQL thinks you're connecting from a host the user isn't allowed from. For example, your user is defined as 'app'@'localhost' but you're connecting from 192.168.1.100. MySQL checks both username and host — they must match exactly.

Check what hosts are allowed:

SELECT user, host FROM mysql.user WHERE user = 'youruser';

If you see only localhost but you're connecting remotely, add a new entry:

CREATE USER 'youruser'@'192.168.1.%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'youruser'@'192.168.1.%';
FLUSH PRIVILEGES;

Or use % as a wildcard — but I don't recommend that unless you're on a trusted network. 'youruser'@'%' allows connections from anywhere, which is a security hole you don't want.

The reason localhost and 127.0.0.1 are treated differently: MySQL resolves localhost as a Unix socket connection, while 127.0.0.1 goes through TCP/IP. If your user is defined for localhost but you connect with -h 127.0.0.1, it'll fail.

3. Corrupted mysql.user Table or Missing Root Access

This is rarer but happens after a crash or partial upgrade. The mysql.user table gets corrupted, or the root password was set but you've forgotten it entirely.

The fix: Bypass authentication by starting MySQL with --skip-grant-tables. This disables all privilege checking — you can log in without a password.

Stop MySQL first:

sudo systemctl stop mysql

Start it in safe mode:

sudo mysqld_safe --skip-grant-tables &

Then connect:

mysql -u root

Once in, reload the grant tables manually:

FLUSH PRIVILEGES;

Now reset the root password:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'newrootpassword';

Stop the safe mode MySQL and start normally:

sudo killall mysqld
sudo systemctl start mysql

Important: Leaving --skip-grant-tables running is like leaving your front door open — anyone who can reach the MySQL port can access all your data. Don't do it in production. Restart normally as soon as you're done.

A real-world trigger: I've seen this happen after a mysql_upgrade failed midway. The mysql.user table had mismatched column definitions, and MySQL couldn't parse its own grants. The only clean fix was restoring from a backup or rebuilding the table.

Quick-Reference Summary Table