22

I've created a database and a user, and allowed access via the following:

create user 'someuser'@'%' identified by 'password';
grant all privileges on somedb.* to 'someuser' with grant option;

however, when I try to connect to MySQL I get the following error:

$ mysql -u someuser -p
> Enter Password:
> ERROR 1045 (28000): Access denied for user 'someuser'@'localhost' (using password: YES)

If "%" is the wildcard, then wouldn't it also enable localhost? However, if I do not specify that I want to use a password, then I can connect just fine to the database, which makes no sense because I'm specifying a password when I created the user.

Wayne Molina
  • 915
  • 4
  • 13
  • 24

5 Answers5

20

Try connecting with mysql -u someuser -p -h 127.0.0.1.

If you can connect without a password, either you have saved credentials in a .my.cnf or you have created an account that allows access without a password.


This comment from the mysql docs may also be related.

http://dev.mysql.com/doc/refman/5.1/en/access-denied.html

If you cannot figure out why you get Access denied, remove from the user table all entries that have Host values containing wildcards (entries that contain '%' or '_' characters). A very common error is to insert a new entry with Host='%' and User='some_user', thinking that this allows you to specify localhost to connect from the same machine. The reason that this does not work is that the default privileges include an entry with Host='localhost' and User=''. Because that entry has a Host value 'localhost' that is more specific than '%', it is used in preference to the new entry when connecting from localhost! The correct procedure is to insert a second entry with Host='localhost' and User='some_user', or to delete the entry with Host='localhost' and User=''.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
9

I'm pretty sure you need the following:

grant all privileges on somedb.* to 'someuser'@'%' with grant option;

Your GRANT statement lacks a hostname declaration.

Asinine Monkey
  • 387
  • 2
  • 8
7

If you are unable to connect to mysql using someuser@'%' where '%' is the wildcard for the hostname, then make sure you don't have ''@localhost entry in your user table. Confirm using the following SQL statement:

    mysql> SELECT * FROM user WHERE user='' AND host='localhost';

If ''@localhost is existing, then remove it by issuing the following SQL statement:

    mysql> DELETE FROM user WHERE user='' AND host='localhost';

then lastly

    FLUSH PRIVILEGES;

Now someuser@'%' will connect to the database.

  • Granting 'username'@'localhost' privileges will not cause grants on the same user from a different location to not work. – tacotuesday Nov 21 '12 at 20:11
  • how is this relevant? what does the '' user at 'localhost' cause? – Steve Buzonas Jan 29 '15 at 23:27
  • 1
    @SteveBuzonas This is absolutely relevant. It provides a code example for the answer that Zoredache posted. Localhost is more specific than '%', so if you attempt to connect via localhost with a user that only has access at '%', the localhost entry is more specific, so mysql attempts to login at localhost, but expects an empty username and empty password. Since those are not the credentials provided, you get the access denied error. By removing these entries, it allows access for users at '%'. – bstakes Feb 06 '15 at 14:33
  • @bstakes the default behavior of the mysql client is to use your shell username if you don't specify one. the question has a user in the example and in the error message. i was curious how a '' user would conflict with a named user. is '' a wildcard? – Steve Buzonas Feb 06 '15 at 15:35
  • @SteveBuzonas '' is functioning like a wildcard with respect to localhost. From the MySQL Docs and shown in an answer above referencing the default that you mentioned: "Because that entry has a Host value 'localhost' that is more specific than '%', it is used in preference to the new entry when connecting from localhost! The correct procedure is to insert a second entry with Host='localhost' and User='some_user', or to delete the entry with Host='localhost' and User=''." – bstakes Feb 06 '15 at 19:52
  • Thank you so much for this. I had this exact same issue on a production server and it was driving me nuts to not understand why it wasn't working. – Yanick Girouard Mar 29 '17 at 01:07
4

My understanding, and I'm prepared to be corrected on this, is that MySQL treats localhost separately to %. i.e. localhost is not included in the wildcard.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
  • The examples provided in http://dev.mysql.com/doc/refman/5.1/en/connection-access.html lead me to believe this may not be accurate. Do you have references otherwise? – Warner Mar 15 '10 at 13:24
  • My understanding of this matter is based on others reporting the same issue, both in print and verbally, and resolving it by creating 2 users, using the "%" and "localhost". I can't recall ever actually seeing it officially documented though. – John Gardeniers Mar 15 '10 at 21:37
  • 1
    This seems to be correct on Ubuntu 12.04 LTS at least – Dex May 31 '13 at 02:09
  • What happened to me is that I had `user@%` and it didn't worked until I included `user@localhost`. Then I saw the answer https://stackoverflow.com/a/29421084/4850646 and realized that I had an anonymous user with host `localhost`. I removed all the anonymous users and was able to access from `localhost` for that user, **even after removing** `user@localhost` (and letting only `user@%`). It seems that because `localhost` is more specific than `%`, it tries first the `localhost` user, **even if it is an anonymous user!** – Lucas Basquerotto May 16 '19 at 14:28
0

Have you run flush privileges; after creating the user? If you don't, changes to users/permissions won't take until after the server is restarted.

Then, check you don't have a '%'@'localhost' entry.

caelyx
  • 699
  • 3
  • 7
  • 4
    using 'create user' and 'grant' automatically flushes privileges. You should only need to flush privileges if you are directly manipulating the mysql database. – Zoredache Mar 15 '10 at 05:59