Fix: ERROR 1045 (28000): Access denied for user ‘appuser’@’localhost’ (using password: YES)

The full message from the mysql client looks like this:

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

Error 1045 (ER_ACCESS_DENIED_ERROR, SQLSTATE 28000) means the server reached authentication and refused it. The message tells you three useful things: the user name, the host the server thinks you came from, and whether a password was sent (YES) or not (NO).

Not the same problem

If you see ERROR 2002 ... Can't connect to local MySQL server through socket '/tmp/mysql.sock' or ERROR 2003: Can't connect to MySQL server on 'host_name', you never reached authentication: the server is not running, or the client uses the wrong socket, host or port. Fix that first (systemctl status mysql or mysqld, check socket, port and bind_address).

Cause 1: wrong password or a stale password in an option file

(using password: YES) with the wrong password is the most common case. If you get the error even though you did not type -p, a client option file (~/.my.cnf, /etc/my.cnf) is supplying an old password. Test without option files:

mysql --no-defaults -u appuser -p -h 127.0.0.1

Also check quoting: with -p there must be no space before the password (-pSECRET), and special characters such as $ or ! may be changed by your shell. Typing the password at the prompt avoids both problems.

(using password: NO) means the account has a password but none was sent: add -p.

Cause 2: the host part does not match

Accounts are 'user'@'host'. An account 'appuser'@'10.0.0.%' does not match a login from localhost, and connecting to localhost on Unix uses the socket, while -h 127.0.0.1 uses TCP. Ask an administrator to list what exists:

SELECT user, host, plugin, account_locked FROM mysql.user WHERE user IN ('appuser', '');

If the right user/host pair is missing, create it rather than widening an existing account to '%':

CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'CHANGE_ME';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'appuser'@'localhost';

Cause 3: an anonymous account wins

Some installations create anonymous accounts (User = ''). The manual explains that ''@'localhost' is more specific than 'appuser'@'%', so a local login matches the anonymous row and fails with your password. Check what you were matched as when you can log in at all: SELECT USER(), CURRENT_USER();. The fix is to create 'appuser'@'localhost' or remove the anonymous account:

SHOW GRANTS FOR ''@'localhost';
DROP USER ''@'localhost';

Cause 4: password changed or the account is locked

Reset the password as an administrator and check that the account is not locked:

ALTER USER 'appuser'@'localhost' IDENTIFIED BY 'NEW_CHANGE_ME';
ALTER USER 'appuser'@'localhost' ACCOUNT UNLOCK;

Cause 5: the root account uses socket authentication (MariaDB)

On MariaDB 10.4 and later, root@localhost tries unix_socket authentication first and its database password starts out invalid, so mysql -u root -p as a normal user is refused. Log in as the operating system root with sudo mariadb, then set a password or create a separate admin account.

Related messages

• Host ... is not allowed to connect to this MySQL server: no account exists for the client’s host at all.
• Access denied for user 'appuser'@'%' to database 'shop' (error 1044): login worked, but the account has no privileges on that database. Fix it with GRANT.
• Authentication requires secure connection: a caching_sha2_password account over plain TCP without TLS; use TLS or --get-server-public-key.

If root itself is locked out, follow the manual’s root password reset procedure. It involves restarting with --skip-grant-tables, which disables all access checks, so do it only with networking disabled and restart normally right afterwards.

Official documentation

• MySQL 8.4: Troubleshooting problems connecting to MySQL
• MySQL 8.4 error reference: server error message reference
• MariaDB: Authentication from MariaDB 10.4