How to fix ERROR 1131: Anonymous user can't change passwords in MySQL

First, confirm that you are indeed logged in as an anonymous user. You can check this by running:

SELECT USER();

If the output shows something like @localhost or @% with an empty username part, you are using an anonymous account. A normal user would display username@hostname.

Disconnect from the current anonymous session and reconnect with a named user account that has ALTER USER privileges. The root user is ideal:

mysql -u root -p

Enter the root password when prompted. Once connected as root, you can now change passwords for any user:

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

This is the most straightforward solution for production environments.

Fresh MySQL installations include anonymous accounts by default that should be removed before production use. Connect as root and execute:

DROP USER ''@'localhost';
DROP USER ''@'%';
FLUSH PRIVILEGES;

This removes both the localhost and wildcard anonymous accounts. Verify they are gone:

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

Should return an empty result set.

If you are encountering this error when using the --init-file startup option, MySQL is running in a state where the ACL cache is not initialized. Add a FLUSH PRIVILEGES command before attempting password changes:

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

The FLUSH PRIVILEGES statement reloads the user grant tables and initializes the in-memory ACL cache, allowing subsequent password-change commands to work properly.

If you cannot connect with a named user, start MySQL with the --skip-grant-tables option to bypass authentication entirely:

mysqld --skip-grant-tables &

Then connect without credentials:

mysql -u root

Within that session, reload the grant tables and create/update a user:

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

After the password is set, stop the server and restart normally. This method is only for recovery situations, not production use.

If you are logged in as a named user but still receive error 1131, verify the user has the required privileges:

SHOW GRANTS FOR 'youruser'@'localhost';

The output should include ALTER USER or ALL PRIVILEGES. If not, grant the necessary privilege using root:

GRANT ALTER USER ON *.* TO 'youruser'@'localhost';
FLUSH PRIVILEGES;

Note: Some users may only have user-level privileges, which do not permit password changes for other users. They can only change their own password if they are authenticated with their own username.