Fix MySQL Error 1045: Access Denied for User

Overview

MySQL error 1045 means your connection was refused at the authentication stage. The full message looks like this:

ERROR 1045 (28000): Access denied for user 'username'@'localhost' (using password: YES)

The frustrating part is that the error is intentionally vague. MySQL won’t tell you whether the username doesn’t exist, the password is wrong, or the user simply isn’t allowed to connect from that host. That’s by design — it doesn’t leak information — but it makes debugging annoying.

This article covers every common cause of MySQL error 1045: wrong credentials, missing host permissions, plugin mismatches, and socket authentication issues. Whether you’re running a WordPress site on shared hosting, managing a database on a VPS SSD Hosting plan, or dealing with a misbehaving app on a dedicated server, one of the scenarios below will match your situation.

Prerequisites

• SSH access to your server (for VPS/dedicated) or access to cPanel/WHM
• Root or sudo privileges (for resetting passwords or editing MySQL config)
• MySQL 5.7+, MySQL 8.0, or MariaDB 10.4+ — note where behaviour differs
• The exact username and hostname from the error message — copy it precisely

Step-by-Step Instructions

Step 1 — Read the Error Message Carefully

Before touching anything, look at the hostname in the error. There’s a big difference between:

Access denied for user 'myuser'@'localhost'
Access denied for user 'myuser'@'192.168.1.50'

MySQL treats localhost and 127.0.0.1 as different hosts in some configurations. A user granted access on localhost may be denied when the app connects via TCP to 127.0.0.1. This is a common gotcha that wastes a lot of time.

Step 2 — Verify the User Exists and Check Their Host

Log in as root and run:

SELECT user, host, plugin FROM mysql.user WHERE user = 'myuser';

If the user doesn’t appear at all, it doesn’t exist — skip to Step 4 to create it. If it exists but the host column shows % and you’re connecting from localhost, or vice versa, that’s your problem.

📝 Note: In MariaDB 10.4+ and MySQL 8.0, also check the plugin column. If it shows auth_socket or unix_socket, the user authenticates via the OS user — not a password. Password-based connections will always fail for that account regardless of what password you use.

Step 3 — Reset the User’s Password

If the user exists but the password is wrong, reset it. For MySQL 8.0:

ALTER USER 'myuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NewStrongPassword';
FLUSH PRIVILEGES;

For MariaDB 10.4+:

ALTER USER 'myuser'@'localhost' IDENTIFIED BY 'NewStrongPassword';
FLUSH PRIVILEGES;

⚠ Warning: Replace NewStrongPassword with a real password. Never leave placeholder values in production. Use a password manager to generate something strong.

Step 4 — Create the User With Correct Permissions

If the user doesn’t exist, create it and grant access to the right database:

CREATE USER 'myuser'@'localhost' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON mydatabase.* TO 'myuser'@'localhost';
FLUSH PRIVILEGES;

If the app connects remotely, replace localhost with the actual connecting IP — for example 'myuser'@'203.0.113.45'. Using '%' grants access from any IP, which is convenient but poor practice on production servers.

Step 5 — Fix Root Access Issues (Socket Auth)

On Ubuntu 20.04/22.04/24.04 and Debian systems, the MySQL/MariaDB root user uses socket authentication by default. This means mysql -u root -p fails unless you’re running the command as the OS root user. This also causes mysql_secure_installation to fail with error 1045.

To switch root to password authentication:

sudo mysql

Then inside the MySQL prompt:

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YourRootPassword';
FLUSH PRIVILEGES;
EXIT;

Now re-run mysql_secure_installation normally:

sudo mysql_secure_installation

📝 Note: On cPanel servers, don’t manually alter the root MySQL password without updating it in WHM under Home > SQL Services > MySQL Root Password. If cPanel loses track of the root password, several services break silently.

Step 6 — Fix Error 1045 in cPanel

If you’re on shared hosting or a cPanel VPS, you can’t log in as MySQL root directly. Use the cPanel interface:

1. Log in to cPanel and click MySQL Databases.
2. Scroll to Current Users and click Change Password next to the affected user.
3. Update the password and copy it exactly into your app’s config file (wp-config.php, .env, database.yml, etc.).
4. Make sure the user is actually assigned to the database — scroll to Add User To Database and check.

It’s easy to create a MySQL user in cPanel and forget to add them to the database. The user can exist, the password can be correct, and the connection still fails with error 1045 because no privileges were ever granted.

Step 7 — Check Your App’s Connection Config

If the credentials look right on the MySQL side, the problem is often in the app config. For WordPress, open wp-config.php:

define( 'DB_NAME',     'your_database_name' );
define( 'DB_USER',     'your_db_user' );
define( 'DB_PASSWORD', 'your_db_password' );
define( 'DB_HOST',     'localhost' );

Confirm each value matches exactly what’s in MySQL. One trailing space or copied quote mark will cause this error.

📝 Note: If your server uses a MySQL socket instead of TCP, DB_HOST might need to be a socket path like /var/run/mysqld/mysqld.sock rather than localhost. Check with your hosting provider if you’re unsure.

Common Issues and Troubleshooting

Password is Correct But Error 1045 Still Appears

The most likely cause is a host mismatch. MySQL users are defined as user@host pairs. A user created as myuser@localhost is a completely different account from myuser@127.0.0.1. Run the SELECT user, host FROM mysql.user query from Step 2 and confirm the host matches exactly how the app is connecting.

Error 1045 After Migrating to a New Server

Database dumps don’t always include user/privilege records from the mysql system database. After a migration, databases exist but users may not. Re-create the MySQL users manually on the new server and re-grant privileges. If you used mysqldump --all-databases, it should include the grant tables, but always verify with the SELECT user, host FROM mysql.user check.

Remote App Getting Error 1045

If your app is on a separate server (common in multi-server or cloud setups), the MySQL user must be created with the app server’s IP as the host, not localhost. You also need to make sure MySQL is listening on a non-loopback interface — check bind-address in /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu) or /etc/my.cnf (CentOS/AlmaLinux). If it’s set to 127.0.0.1, remote connections are blocked at the network level before MySQL even checks credentials.

# Check current bind address
grep bind-address /etc/mysql/mysql.conf.d/mysqld.cnf

mysql_secure_installation Fails With Error 1045

This is the socket authentication issue described in Step 5. On Debian/Ubuntu systems, run sudo mysql first, change root’s auth plugin to mysql_native_password, flush privileges, exit, then re-run the script. Don’t skip the FLUSH PRIVILEGES — without it, the change doesn’t take effect for the current session.

Error 1045 in WHM After MySQL Upgrade

MySQL 8.0 changed the default authentication plugin from mysql_native_password to caching_sha2_password. Some older PHP versions and cPanel-managed services don’t support caching_sha2_password. After an in-place upgrade, existing apps may break. Check the plugin column in mysql.user for affected accounts and alter them back to mysql_native_password as shown in Step 3. WHM’s MySQL upgrade wizard sometimes handles this — but not always.

FAQ