I'm trying to backup my MySQL databases in RackSpace to AWS.
I have followed the advice from this blog and have set log_bin_trust_function_creators=1 in my AWS RDS control panel and rebooted my db instance.
However after some time and some bits being moved I get the following error:
Warning: Using a password on the command line interface can be insecure.
16GiB 0:36:39 [7.43MiB/s] [7.43MiB/s]
ERROR 1227 (42000) at line 21566: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
I know there are a few triggers in my db and perhaps a couple of other goodies, notwithstanding my grants on the aws all seem sufficient:
mysql> SHOW GRANTS;
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root#% |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'root'#'%' IDENTIFIED BY PASSWORD <secret> WITH GRANT OPTION |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
What could be the problem? How do I solve it?
EDIT
Instead of dumping to ssh I just dumped it to sed -n '21565,21567p' so I assume that the output (line numbers) should be correct:
/*!50001 SET collation_connection = utf8_general_ci */;
/*!50001 CREATE ALGORITHM=UNDEFINED */
/*!50013 DEFINER=`root`#`127.0.0.1` SQL SECURITY DEFINER */
The problem here was the definer line in your DB. Always keep in mind:
You can specify a DEFINER value other than your own account only if you have the SUPER privilege.(Read below)
http://dev.mysql.com/doc/refman/5.6/en/stored-programs-security.html
And with RDS always keep in mind you don't get the Super Privilege.
I am connecting to a MySQL (5.08) database running on a linux machine from a web application running in tomcat.
I get the following exception when I try to execute a stored procedure:
com.hp.hpl.chaos.web.exception.DBException: getNextValue for operatorinstance[Additional Information from SQL Exception][SQLErrorCode: 0 SQLState: S1000
at com.hp.hpl.chaos.web.util.SQLUtil.getNextValue(SQLUtil.java:207)
..............
Caused by: java.sql.SQLException: User does not have access to metadata required to determine stored procedure parameter types. If rights can not be granted, configure connection with "noAccessToProcedureBodies=true" to have driver generate parameters that represent INOUT strings irregardless of actual parameter types.
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:910)
at com.mysql.jdbc.DatabaseMetaData.getCallStmtParameterTypes(DatabaseMetaData.java:1619)
at com.mysql.jdbc.DatabaseMetaData.getProcedureColumns(DatabaseMetaData.java:4034)
at com.mysql.jdbc.CallableStatement.determineParameterTypes(CallableStatement.java:709)
at com.mysql.jdbc.CallableStatement.<init>(CallableStatement.java:513)
at com.mysql.jdbc.Connection.parseCallableStatement(Connection.java:4583)
at com.mysql.jdbc.Connection.prepareCall(Connection.java:4657)
at com.mysql.jdbc.Connection.prepareCall(Connection.java:4631)
at com.hp.hpl.chaos.web.util.SQLUtil.getNextValue(SQLUtil.java:196)
... 17 more
After installing mysql on the machine. I have given the follwing grant options to root
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'#'%' IDENTIFIED BY 'pass';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
In the java class..
I am connecting to the db as follows:
String url = "jdbc:mysql://ipaddress:3306/test";
con = DriverManager.getConnection(url,"root", "pass");
I have also tried the url with the noAccessToProcedureBodies=true option included.
Can someone tell me what is wrong here? Is there anything I need to check?
There are two ways to solve this:
set the connection's noAccessToProcedureBodies=true property
For example as part of the connection string:
jdbc:mysql://ipaddress:3306/test?noAccessToProcedureBodies=true
The JDBC driver will then create "INOUT" strings for the arguments without requiring meta data like the exception says.
Grant SELECT privileges on mysql.proc to the database user
For example in the mysql prompt:
GRANT SELECT ON mysql.proc TO 'user'#'localhost';
Of course this would allow the application to read the entire mysql.proc table that contains information about all stored procedures in all databases (including source code).
Following steps worked for me in mysql
Step 1 : add follwong
Connection con = DriverManager.getConnection("jdbc:mysql://ipaddress:3306/logparser?noAccessToProcedureBodies = true ",
"root", "");
Step 2 :
GRANT ALL ON logparser.proc TO root#'%'; where logparser is DB name and proc is procedure name.
Running below queries should fix your issue.
GRANT <SELECT, CREATE, UPDATE, DELETE, ALL> PRIVILEGES ON mysql.proc TO '<user>'#'%';
FLUSH PRIVILEGES;
You can change the definer in the mysql.proc table to your database user.
select * from mysql.proc;
choose the stored proc that has problem and change the definer to 'yourdbuser'#'localhost'.
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...)