I have not been introduced to mysql, but had to work with it. I installed it and tried to run this:
mysql> CREATE TABLE h7vsk1200001 (quid VARCHAR(15), suid VARCHAR(15), iden FLOAT, alen INT, mism INT, gapo INT, qsta INT, qend INT, ssta INT, send INT, eval FLOAT, bits INT);
Which I understand is the basis for a table, with its names for columns and its datatypes. Whenever I run it, I get this error message:
bash: error sintáctico cerca del elemento inesperado `('
By the way, I'm using Ubuntu 14.04 if that matters. Also, if I try to run the CREATE TABLE command without arguments I get:
$ mysql> CREATE TABLE
ERROR 1045 (28000): Access denied for user 'carlos'#'localhost' (using password: NO)
Consider that I have little experience with bash and no experience with mysql (as you may have denoted)
You first need to launch the mysql shell. You can't run queries like this in bash: you need to use a MySQL client. You're getting the first error because bash is trying to parse the parentheses, and the second error is the result of you running the mysql command while piping (>) the output to a new file called CREATE.
Note you're getting the ACCESS DENIED because you apparently don't have access as the user carlos without a password. Use mysql -u myusername -p to log in with username myusername and to have mysql prompt for a password.
thom#lethe-arch:~$ # bash shell
thom#lethe-arch:~$ mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 443
Server version: 10.0.14-MariaDB-log MariaDB Server
Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| test |
+--------------------+
2 rows in set (0.01 sec)
mysql> -- type queries here
(Note: MariaDB is a fork of MySQL and behaves exactly the same)
Seems you have to create a user 'carlos' and allow necessary permissions like:
mysql> use mysql;
mysql> CREATE USER 'carlos'#'localhost' IDENTIFIED BY 'yourpassword';
mysql> GRANT ALL PRIVILEGES ON . TO 'carlos'#'localhost' WITH GRANT OPTION;
Does anyone know why I get this error when running mysqlimport?
mysqlimport -u someone -pwhatever --columns=a,b,c,d,e bar /var/tmp/baz.sql
mysqlimport: Error: 1045, Access denied for user 'someone'#'%' (using password: YES), when using table: baz
However...
mysql -u someone -pwhatever
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 199
Server version: 5.1.41-3ubuntu12.10 (Ubuntu)
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show grants;
+------------------------------------------------------------------------------------------------------------+
| Grants for someone#% |
+------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'someone'#'%' IDENTIFIED BY PASSWORD '*BLAHBLAHBLAH' |
| GRANT ALL PRIVILEGES ON `bar`.* TO 'someone'#'%' |
+------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
mysql>
You can avoid the need for the extra privileges by using the --local parameter to mysqlimport:
--local, -L
Read input files locally from the client host.
OK, it turns out that the FILE privilege is a "global" privilege, which apparently means you can't selectively enable it on certain databases, tables. etc. That's why my previous grant statement on bar.* had no effect:
GRANT ALL PRIVILEGES ON `bar`.* TO 'someone'#'%'
You need to grant FILE privileges on *.*:
GRANT FILE ON *.* to 'someone'#'%';
Hope this helps someone.
Some would instead opt for this command, skipping the extra FILE grant.
mysql -u username -p <yourdbname> < yourfile.sql
mysqlimport is a command-line interface to the LOAD DATA INFILE statement, for which you need the 'FILE' privilege (server level).
From LOAD DATA INFILE syntax:
Also, to use LOAD DATA INFILE on server files, you must have the FILE privilege.
TLDR: Use the `--set-gtid-purged=OFF` Arg in MySQLDump
When doing mysqldump -u username -p to create the file you're going to import elsewhere, throw in the argument of --set-gtid-purged=OFF.
GTIDs are needed for replication, and probably don't apply to what you're doing if you just want to copy/paste DB 1 to DB 2.
General Debugging Help
My debugging process here was a little bit different than what others have done. I suggest this to debug: Change your .sql to the simplest possible thing, maybe just one single CREATE TABLE statement, and see if it runs.
If it runs, then these are things that you want to remove from your SQL import file:
Any line setting ##GLOBAL.GTID.
SET #MYSQLDUMP_TEMP_LOG_BIN = ##SESSION.SQL_LOG_BIN;
SET ##SESSION.SQL_LOG_BIN= 0;
SET ##SESSION.SQL_LOG_BIN = #MYSQLDUMP_TEMP_LOG_BIN;
As you can see, it's a lot of GTID stuff, which is transaction ID info used for doing replication. So, these are important when doing server replication, but not when doing basically a copy-paste of one DB to another DB, and in that case we can drop them.
I seem to be unable to re-create a simple user I've deleted, even as root in MySQL.
My case: user 'jack' existed before, but I deleted it from mysql.user in order to recreate it. I see no vestiges of this in that table. If I execute this command for some other, random username, say 'jimmy', it works fine (just as it originally did for 'jack').
What have I done to corrupt user 'jack' and how can I undo that corruption in order to re-create 'jack' as a valid user for this installation of MySQL?
See example below. (Of course, originally, there was much time between the creation of 'jack' and his removal.)
mysql> CREATE USER 'jack'#'localhost' IDENTIFIED BY 'test123';
Query OK, 0 rows affected (0.00 sec)
mysql> select user,host from user;
+------------------+-----------------+
| user | host |
+------------------+-----------------+
| root | 127.0.0.1 |
| debian-sys-maint | localhost |
| jack | localhost |
| root | localhost |
| root | russ-elite-book |
+------------------+-----------------+
5 rows in set (0.00 sec)
mysql> delete from user where user = 'jack';
Query OK, 1 row affected (0.00 sec)
mysql> select user,host from user;
+------------------+-----------------+
| user | host |
+------------------+-----------------+
| root | 127.0.0.1 |
| debian-sys-maint | localhost |
| root | localhost |
| root | russ-elite-book |
+------------------+-----------------+
4 rows in set (0.00 sec)
mysql> CREATE USER 'jack'#'localhost' IDENTIFIED BY 'test123';
ERROR 1396 (HY000): Operation CREATE USER failed for 'jack'#'localhost'
mysql> CREATE USER 'jimmy'#'localhost' IDENTIFIED BY 'test123';
Query OK, 0 rows affected (0.00 sec)
mysql> select user,host from user;
+------------------+-----------------+
| user | host |
+------------------+-----------------+
| root | 127.0.0.1 |
| debian-sys-maint | localhost |
| jimmy | localhost |
| root | localhost |
| root | russ-elite-book |
+------------------+-----------------+
5 rows in set (0.00 sec)
yes this bug is there. However, I found a small workaround.
Assume the user is there, so drop the user
After deleting the user, there is need to flush the mysql privileges
Now create the user.
That should solve it. Assuming we want to create the user admin # localhost, these would be the commands:
drop user admin#localhost;
flush privileges;
create user admin#localhost identified by 'admins_password'
Try doing a FLUSH PRIVILEGES;. This MySQL bug post on that error code appears to report some success in a case similar to yours after flushing privs.
This bug has been sitting on bugs.mysql.com since 2007 and this thread is mainly just a parroting of all those wrong answers even up to a year ago.
According to the MySQL documentation, commands like CREATE USER, GRANT, REVOKE, and DROP USER do not require a subsequent FLUSH PRIVILEGES command. It's quite clear why, if one reads the docs. It's because altering the MySQL tables directly does not reload the info into memory; yet the plethora of solutions to this bug claim that FLUSH PRIVILEGES is the answer.
This also may not even be a bug. It is a documentation conspiracy - docs vary in one critical place from version to version.
13.7.1.2. DROP USER Syntax
...
DROP USER user [, user] ...
...
DROP USER 'jeffrey'#'localhost';
If you specify only the user name part of the account name, a host name part of '%' is used.
DROP USER as present in MySQL 5.0.0 removes only accounts that have no privileges. In MySQL 5.0.2, it was modified to remove account privileges as well. This means that the procedure for removing an account depends on your version of MySQL.
As of MySQL 5.0.2, you can remove an account and its privileges as follows:
DROP USER user;
The statement removes privilege rows for the account from all grant tables.
The only time I get this error is when I do DROP USER user; like the doc suggests, but MySQL does not treat the '%' as a wildcard in a way that would drop all users at all hosts. It's not so wild after all. Or, it may be that it sometimes works when it deletes the localhost user and then tries to delete the one at %.
It's clear to me that when it tries to delete the user at %, it issues an error message and quits. Subsequent CREATE USER at localhost will fail because the localhost user was never deleted. There seems to be no need to waste time digging in the grant tables looking for ghosts as one poster suggested.
I see 7 votes for:
DROP USER 'jack#localhost'; // completely delete the account
Which is interpreted as DROP USER 'jack#localhost'#'%'; # wrong
There actually seems to be a real bug that generates the same error message, but it has to do with the first created user (after a new mysql server install) being dropped. Whether that bug has been fixed, I don't know; but I don't recall that happening lately and I'm up to ver 5.5.27 at this time.
If you use a DELETE statement on the mysql.user table in an attempt to remove a user, then attempt to re-establish the user with CREATE USER, you will get a 1396 error. Get rid of this error by running DROP USER 'username'#'host';
DELETE
FROM mysql.user
WHERE user = 'jack';
(You will get 1396 errors if you attempt to re-create jack)
CREATE USER 'jack'#'localhost' IDENTIFIED BY PASSWORD '*Fi47ytFF3CD5B14E7EjkjkkC1D3F8086A5C0-krn';
(Get out of this situation by running DROP USER)
DROP USER 'jack'#'localhost';
(I suppose FLUSH PRIVILEGES can't hurt, but definitely drop the user first.)
You shouldn't be manually deleting users that way. MySQL has REVOKE syntax for removing privileges and DROP USER for deleting them:
REVOKE priv1,priv2,priv3,etc... FROM 'jack#localhost'; // remove certain privileges
DROP USER 'jack#localhost'; // completely delete the account
Best to use the tools provided rather than mucking around in the background.
Drop the user, flush the privileges; then, create the user. It does work!
try delete from mysql.db where user = 'jack' and then create a user
Check if is
'user'#'%'
or
'user'#'localhost'
In MySQL 5.6 using Drop user userid; does not work. Use: Drop user 'userid'#'localhost'; and/or Drop user 'userid'#'%';. In this way I was able to drop the user and recreate it.
If you want to delete a user with sql, you need to delete the related data in these tables: columns_priv, db, procs_priv, tables_priv. Then execute flush privileges;
two method
one :
setp 1: drop user 'jack'#'localhost';
setp 2: create user 'jack'#localhost identified by 'ddd';
two:
setp 1: delete from user where user='jack'and host='localhost';
setp 2: flush privileges;
setp 3: create user 'jack'#'localhost' identified by 'ddd';
I had the same error. But command "FLUSH PRIVILEGES;" didn't help.
I did like that:
CREATE USER 'jimmy'#'localhost' IDENTIFIED BY 'test123';
UPDATE mysql.user SET USER='jack' WHERE USER='jimmy';
BUG of MySql Solved: Error Code-1396
Whenever you had try to run query which create a User as Shown Below.
MySql> CREATE USER 'springstudent'#'localhost' IDENTIFIED BY 'springstudent';
GRANT ALL PRIVILEGES ON * . * TO 'springstudent'#'localhost';
But when you try to run query which create user within all previleges,
Due to bug it create gives previleges without showing user
Because of this Problem we need to use this script for flush priviledges
MySql> drop user 'springstudent'#'localhost';
flush privileges;
create user admin#localhost identified by 'admins_password'
After deleting the user, there is need to flush the mysql privileges
Then Create User again
Gotchaaa.... Solved....
A simple work around on this issue. As "delete" command only removes the user record in "user" table of "mysql" database, we could add it back and then drop the user completely. Then you could create user with same name.
Step 1. find the record format of user table in mysql database
use mysql;
select * from user;
Step 2. According to the columns showed in step1, create a dummy record with the user name. Insert it into the table, for example, be reminded to replace the "username" with your username.
Insert into user value ('%','username','N','N','N','N','N',
'N','N','N','N','N','N','N','N','N','N','N','N','N','N','N',
'N','N','N','N','N','N','N','N','N','','','','','0','0','0',
'0','mysql_native_password',
'*52C5E3AC6BC5E2E0BFF86978BF62A1481AC79D58','N',
'2016-12-10 23:59:12',null,'N');
Note: sometimes you may encounter issues in inserting, just change the data to make it work.
Step 3. Drop the user.
drop user username;
Now you are able to create user with same name.
Funnily enough the MySQL workbench solved it for me. In the Administration tab -> Users and Privileges, the user was listed with an error. Using the delete option solved the problem.
Seems you need to create user for your database and grant privileges for created user
--> create user for Data base
CREATE USER <'username'>#'%'IDENTIFIED BY <'password'>;
ex - CREATE USER 'root'#'%'IDENTIFIED BY 'root';
--> Grant Privileges
FLUSH PRIVILEGES;
GRANT ALL PRIVILEGES ON <db name>.* TO '<username>'#'%';
ex- GRANT ALL PRIVILEGES ON mydb.* TO 'root'#'%';
This post MySQL ERROR 1045 (28000): Access denied for user 'bill'#'localhost' (using password: YES) is useful. Sometimes, there is an anonymous user ''#'localhost' or ''#'127.0.0.1'. So, to solve the problem,
first drop the user whose 'create user' failed.
Create new user.
Grant required privileges to the new user.
Flush privileges.
I faced this issue today, and I resolved it by doing the following steps:
1) manually inserting that troubling user providing value of mandatory fields into mysql.user
mysql> insert into user(Host, User, Password, ssl_type)
values ('localhost', 'jack', 'jack', 'ANY');
2)
mysql> select * from user where User = 'jack';
1 row in set (0.00 sec)
3) A.
mysql> drop user jack;
Query OK, 0 rows affected (0.00 sec)
B. mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
C. mysql> create user 'jack' identified by 'jack';
Query OK, 0 rows affected (0.00 sec)
D. mysql> select Host, User, Password, ssl_type from user where User = 'jack';
+-----------+-----------+-------------------------------------------+----------+
| Host | User | Password | ssl_type |
+-----------+-----------+-------------------------------------------+----------+
| localhost | jack | jack | ANY |
| % | jack | *45BB7035F11303D8F09B2877A00D2510DCE4D758 | |
+-----------+-----------+-------------------------------------------+----------+
2 rows in set (0.00 sec)
4) A.
mysql> delete from user
where User = 'nyse_user' and
Host = 'localhost' and
Password ='nyse';
Query OK, 1 row affected (0.00 sec)
B.
mysql> select Host, User, Password, ssl_type from user where User = 'jack';
+------+-----------+-------------------------------------------+----------+
| Host | User | Password | ssl_type |
+------+-----------+-------------------------------------------+----------+
| % | jack | *45BB7035F11303D8F09B2877A00D2510DCE4D758 | |
+------+-----------+-------------------------------------------+----------+
1 row in set (0.00 sec)
Hope this helps.
I had the same problem as OP, and the accepted answer did not work for me. In the comments of the accepted answer, #Rathish posted a solution which worked for me, I wanted to call attention to it.
Here's the link:
https://www.rathishkumar.in/2018/10/Error-1396-HY000-Operation-CREATE-DROP-USER-failed-for-user-host.html
Rathish's solution is to revoke access for all users:
REVOKE ALL ON *.* FROM 'user'#'host';
DROP USER 'user'#'host';
FLUSH PRIVILEGES;
And he also helpfully points out that you can query the following tables by selecting "user" and "host" to determine whether you have a vestigial user left-over from a previous operation:
mysql.user: User accounts, global privileges, and other non-privilege columns
mysql.db: Database-level privileges
mysql.tables_priv: Table-level privileges
mysql.columns_priv: Column-level privileges
mysql.procs_priv: Stored procedure and function privileges
mysql.proxies_priv: Proxy-user privilege
Thank you!
replace localhost by 127.0.0.1
it works for me
Step 1) Open MySQL Command Line Client.
Step 2) Check all the users using : select user, host from mysql.user;
Step 3) Delete the user using : drop user username#localhost;
Step 4) Again create user using MySQL GUI.
Step 5) Problem is solved now.
The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement
I know this is old, but since it is the first result in Google I figured I should add my solution. In my case dropping the user worked fine, but recreating the user gave me a "ERROR 2013 (HY000): Lost connection to MySQL server during query" and "ERROR 2006 (HY000): MySQL server has gone away." I tried the flush privileges -> drop user solution, but still had the same error.
In my case the error was due to a mysql upgrade from 5.1 -> 5.6. Viewing the error logs, I noticed that it said to run mysql_upgrade. Did that and my create user statement worked fine!
I recently got this error.
What worked for me is checking in the mysql workbench 'Users and Privileges' and realizing user still existed.
After deleting it from there, I was able to recreate the user.
mysql> DELETE FROM mysql.db WHERE user = 'jack'
Restart the server:
# mysql.server restart
Then do your CREATE USER command.
My experience with this error resulted from me doing explicit delete from mysql.user, but not from mysql.db
Turns out if the user name in the create exists is in either user or db, you get this error. Solve by doing
delete from mysql.user where User == 'user#bar';
delete from mysql.db where User == 'user#bar';
Just delete the user related data from mysql.db(maybe from other tables too), then recreate both.
I had also faced the same issue, after few searches, I found a solution that worked for me.I hope it will help you.
As you have already created users, now try to do a FLUSH PRIVILEGES on your Mysql console.
This issue is already in MySql bug post.You can also check this one.Now after flushing, you can create a new user.
follow below Steps:
Step-1: Open terminal Ctrl+Alt+T
Step-2: mysql -u root -p , it will ask for your MySQL password.
Now you can able to see Mysql console.
Step-3: CREATE USER 'username'#'host' IDENTIFIED by 'PASSWORD';
Instead of username you can put username you want. If you are running Mysql on your local machine, then type "localhost" instead of the host, otherwise give your server name you want to access.
Ex: CREATE USER smruti#localhost IDENTIFIED by 'hello';
Now new user is created. If you want to give all access then type
GRANT ALL PRIVILEGES ON * . * TO 'newuser'#'localhost';
Now you can quit the MySQL by typing \q.Now once again login through
mysql -u newusername -p , then press Enter. You can see everything.
Hope this helps.
I have several thousand MySQL users all set to allow access from a specific host. The problem is that now I'm going to have two machines (more in the future) which will need to use the same account to access each of their databases.
I'd like a quick and easy (as automated as possible) way to run through and modify the host portion of each user account to fit an internal network wildcard. For example:
'bugsy'#'internalfoo' has access to the 'bugsy' DB.
I want to now allow bugsy access from anywhere on the internal network
'bugsy'#'10.0.0.%' has access to the 'bugsy' DB.
The accepted answer only renamed the user but the privileges were left behind.
I'd recommend using:
RENAME USER 'foo'#'1.2.3.4' TO 'foo'#'1.2.3.5';
According to MySQL documentation:
RENAME USER causes the privileges held by the old user to be those held by the new user.
For reference, the solution is:
UPDATE mysql.user SET host = '10.0.0.%' WHERE host = 'internalfoo' AND user != 'root';
UPDATE mysql.db SET host = '10.0.0.%' WHERE host = 'internalfoo' AND user != 'root';
FLUSH PRIVILEGES;
The more general answer is
UPDATE mysql.user SET host = {newhost} WHERE user = {youruser}
Similar issue where I was getting permissions failed. On my setup, I SSH in only. So What I did to correct the issue was
sudo MySQL
SELECT User, Host FROM mysql.user WHERE Host <> '%';
MariaDB [(none)]> SELECT User, Host FROM mysql.user WHERE Host <> '%';
+-------+-------------+
| User | Host |
+-------+-------------+
| root | 169.254.0.% |
| foo | 192.168.0.% |
| bar | 192.168.0.% |
+-------+-------------+
4 rows in set (0.00 sec)
I need these users moved to 'localhost'. So I issued the following:
UPDATE mysql.user SET host = 'localhost' WHERE user = 'foo';
UPDATE mysql.user SET host = 'localhost' WHERE user = 'bar';
Run SELECT User, Host FROM mysql.user WHERE Host <> '%'; again and we see:
MariaDB [(none)]> SELECT User, Host FROM mysql.user WHERE Host <> '%';
+-------+-------------+
| User | Host |
+-------+-------------+
| root | 169.254.0.% |
| foo | localhost |
| bar | localhost |
+-------+-------------+
4 rows in set (0.00 sec)
And then I was able to work normally again. Hope that helps someone.
$ mysql -u foo -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 74
Server version: 10.1.23-MariaDB-9+deb9u1 Raspbian 9.0
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>
I received the same error with RENAME USER and GRANTS aren't covered by the currently accepted solution:
The most reliable way seems to be to run SHOW GRANTS for the old user, find/replace what you want to change regarding the user's name and/or host and run them and then finally DROP USER the old user. Not forgetting to run FLUSH PRIVILEGES (best to run this after adding the new users' grants, test the new user, then drop the old user and flush again for good measure).
> SHOW GRANTS FOR 'olduser'#'oldhost';
+-----------------------------------------------------------------------------------+
| Grants for olduser#oldhost |
+-----------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'olduser'#'oldhost' IDENTIFIED BY PASSWORD '*PASSHASH' |
| GRANT SELECT ON `db`.* TO 'olduser'#'oldhost' |
+-----------------------------------------------------------------------------------+
2 rows in set (0.000 sec)
> GRANT USAGE ON *.* TO 'newuser'#'newhost' IDENTIFIED BY PASSWORD '*SAME_PASSHASH';
Query OK, 0 rows affected (0.006 sec)
> GRANT SELECT ON `db`.* TO 'newuser'#'newhost';
Query OK, 0 rows affected (0.007 sec)
> DROP USER 'olduser'#'oldhost';
Query OK, 0 rows affected (0.016 sec)
I haven't had to do this, so take this with a grain of salt and a big helping of "test, test, test".
What happens if (in a safe controlled test environment) you directly modify the Host column in the mysql.user and probably mysql.db tables? (E.g., with an update statement.) I don't think MySQL uses the user's host as part of the password encoding (the PASSWORD function doesn't suggest it does), but you'll have to try it to be sure. You may need to issue a FLUSH PRIVILEGES command (or stop and restart the server).
For some storage engines (MyISAM, for instance), you may also need to check/modify the .frm file any views that user has created. The .frm file stores the definer, including the definer's host. (I have had to do this, when moving databases between hosts where there had been a misconfiguration causing the wrong host to be recorded...)