I am preparing to write a complex stored procedure. I figure will need a debugger going so I am trying to use ocelotgui. I have installed it and can connect to my database in mysql. When I type $INSTALL which is required to set up the debugger I am getting this error:
$INSTALL
Need create privilege on xxxmdbug.. Need select privilege on xxxmdbug.. Need insert privilege on xxxmdbug.. Need delete privilege on xxxmdbug.. Need update privilege on xxxmdbug.. Need drop privilege on xxxmdbug.. Need create routine privilege on xxxmdbug.. Need alter routine privilege on xxxmdbug..
It seems that ocelotgui creates a database called xxxmdbug but for some reason it can't on my system. I am running mySQL in Docker and I have modified the mysql.sql to have the following lines dealing with xxxmdbug.
CREATE DATABASE IF NOT EXISTS subs;
CREATE DATABASE IF NOT EXISTS xxxmdbug;
GRANT ALL PRIVILEGES ON subs.* To 'admin'#'%';
GRANT ALL PRIVILEGES ON xxxmdbug.* To 'admin'#'%';
It seems that I can't login with root so that I can GRANT my actual user the privileges. I though that the password for root was "", but I guess not. Anyone?
I assume you downloaded ocelotgui 1.2 from https://github.com/ocelot-inc/ocelotgui.
You might be seeing an error if database xxxmdbug already exists
(if so, drop it). But if the problem is lack of privileges
(you need create, drop, create routine, alter routine, select, insert, update, delete, select on xxxmdbug.*), then there's
nothing ocelotgui can do, good luck finding the root password.
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.
What are the minimum privilege required for a mysql db user to use the mysqldump file and restore.
Cannot use root db user in my case.
Have taken full backup of all schemas in a dump file using mysqldump utility.
Need to know minimum required privileges to be given to a db user(other than root db user) so that it can be used to do restore from mysqldump file.
It is not possible to restore a complete, unmodified dump file to a MySQL Server without the SUPER privilege.
The "root" user is not a magical user. It just happens to be a user that is created by default and has GRANT ALL PRIVILEGES ON *.* ... WITH GRANT OPTION. Another user can be given the same privileges.
Restoring a database essentially means obliterating everything on a server and replacing it with something else, including all the user accounts so SUPER is required.
More limited privileges can be used if certain modifications to the dump file are made, such as removing all DEFINER statements, and modifying the way the mysql schema is handled, but those modifications are an advanced topic with system-specific considerations.
I've started with SUPER, INSERT, & ALTER and tried repeatedly adding new ones until the restore finished successfully.
This is what I've ended up with:
SUPER
ALTER
INSERT
CREATE
DROP
LOCK TABLES
REFERENCES
SELECT
If you have routines and triggers then you'll need these two additionally:
CREATE ROUTINE
TRIGGER
Hope this helps.
From the Mysql official site:
mysqldump requires at least the SELECT privilege for dumped tables,
SHOW VIEW for dumped views, TRIGGER for dumped triggers, and LOCK
TABLES if the --single-transaction option is not used. Certain options
might require other privileges as noted in the option descriptions.
--single-transaction
This option sets the transaction isolation mode to REPEATABLE READ and
sends a START TRANSACTION SQL statement to the server before dumping
data. It is useful only with transactional tables such as InnoDB,
because then it dumps the consistent state of the database at the time
when START TRANSACTION was issued without blocking any applications.
In conclusion, privileges are:
select (required)
lock tables (required)
show views and trigger (optional)
I have a PHP script that calls MySQL's LOAD DATA INFILE to load data from CSV files. However, on production server, I ended up with the following error:
Access denied for user ... (using password: yes)
As a quick workaround, I changed the command to LOAD DATA LOCAL INFILE which worked. However, the same command failed on client's server with this message:
The used command is not allowed with this MySQL version
I assume this has something to do with the server variable: local_infile = off as described here.
Please suggest a workaround that does not involve changing server settings. Note that phpMyAdmin utility installed on the same server appears to accept CSV files though I am not sure it it uses LOAD DATA (LOCAL) INFILE.
Ran into the same issue as root and threw me for a moment
could be an issue with your server settings set with compile
to test login to console with the same user and try your load data command
if you get the same error, try closing console and running
mysql -u USER -p --local-infile=1 DATABASE
now try running load data command again
if it works then you're going to need to restart mysqld with command line option or re-install with configuration option
references (references are for 5.0 but worked for me with 5.5):
http://dev.mysql.com/doc/refman/5.0/en/load-data-local.html
http://dev.mysql.com/doc/refman/5.0/en/mysql-command-options.html#option_mysql_local-infile
I found that I need to connect to database like this:
$dbh=mysql_connect($server,$dbuser,$dbpass,false,128);
Passing 128 in the flags parameter is the key.
See http://www.php.net/manual/en/mysql.constants.php#mysql.client-flags to read more about the flags.
take a look to this permission list, you can add them separately, IE. you can insert but not update, or you can delete but not select, etc...
ALL [PRIVILEGES] Grant all privileges at specified access level except GRANT OPTION
ALTER Enable use of ALTER TABLE
ALTER ROUTINE Enable stored routines to be altered or dropped
CREATE Enable database and table creation
CREATE ROUTINE Enable stored routine creation
CREATE TEMPORARY TABLES Enable use of CREATE TEMPORARY TABLE
CREATE USER Enable use of CREATE USER, DROP USER, RENAME USER, and REVOKE ALL PRIVILEGES
CREATE VIEW Enable views to be created or altered
DELETE Enable use of DELETE
DROP Enable databases, tables, and views to be dropped
EVENT Enable use of events for the Event Scheduler
EXECUTE Enable the user to execute stored routines
FILE Enable the user to cause the server to read or write files
GRANT OPTION Enable privileges to be granted to or removed from other accounts
INDEX Enable indexes to be created or dropped
INSERT Enable use of INSERT
LOCK TABLES Enable use of LOCK TABLES on tables for which you have the SELECT privilege
PROCESS Enable the user to see all processes with SHOW PROCESSLIST
REFERENCES Not implemented
RELOAD Enable use of FLUSH operations
REPLICATION CLIENT Enable the user to ask where master or slave servers are
REPLICATION SLAVE Enable replication slaves to read binary log events from the master
SELECT Enable use of SELECT
SHOW DATABASES Enable SHOW DATABASES to show all databases
SHOW VIEW Enable use of SHOW CREATE VIEW
SHUTDOWN Enable use of mysqladmin shutdown
SUPER Enable use of other administrative operations such as CHANGE MASTER TO, KILL, PURGE BINARY LOGS, SET GLOBAL, and mysqladmin debug command
TRIGGER Enable trigger operations
UPDATE Enable use of UPDATE
USAGE Synonym for “no privileges”
I think you have permision to select, delete, insert, update, but no to do other stuff,
use this command:
SHOW GRANTS
he will show you what you are able to to, in my case.
jcho360> show grants;
+-------------------------------------------------------+
| Grants for jbolivar#localhost |
+-------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'jbolivar'#'localhost' |
+-------------------------------------------------------+
1 row in set (0.00 sec)
When I run the following query I get an error:
SELECT
`a`.`sl_id` AS `sl_id`,
`a`.`quote_id` AS `quote_id`,
`a`.`sl_date` AS `sl_date`,
`a`.`sl_type` AS `sl_type`,
`a`.`sl_status` AS `sl_status`,
`b`.`client_id` AS `client_id`,
`b`.`business` AS `business`,
`b`.`affaire_type` AS `affaire_type`,
`b`.`quotation_date` AS `quotation_date`,
`b`.`total_sale_price_with_tax` AS `total_sale_price_with_tax`,
`b`.`STATUS` AS `status`,
`b`.`customer_name` AS `customer_name`
FROM `tbl_supplier_list` `a`
LEFT JOIN `view_quotes` `b`
ON (`b`.`quote_id` = `a`.`quote_id`)
LIMIT 0, 30
The error message is:
#1449 - The user specified as a definer ('web2vi'#'%') does not exist
Why am I getting that error? How do I fix it?
This commonly occurs when exporting views/triggers/procedures from one database or server to another as the user that created that object no longer exists.
You have two options:
1. Change the DEFINER
This is possibly easiest to do when initially importing your database objects, by removing any DEFINER statements from the dump.
Changing the definer later is a more little tricky:
How to change the definer for views
Run this SQL to generate the necessary ALTER statements
SELECT CONCAT("ALTER DEFINER=`youruser`#`host` VIEW ",
table_name, " AS ", view_definition, ";")
FROM information_schema.views
WHERE table_schema='your-database-name';
Copy and run the ALTER statements
How to change the definer for stored procedures
Example:
UPDATE `mysql`.`proc` p SET definer = 'user#%' WHERE definer='root#%'
Be careful, because this will change all the definers for all databases.
2. Create the missing user
If you've found following error while using MySQL database:
The user specified as a definer ('someuser'#'%') does not exist`
Then you can solve
it by using following :
GRANT ALL ON *.* TO 'someuser'#'%' IDENTIFIED BY 'complex-password';
FLUSH PRIVILEGES;
From http://www.lynnnayko.com/2010/07/mysql-user-specified-as-definer-root.html
This worked like a charm - you only have to change someuser to the name of the missing user. On a local dev server, you might typically just use root.
Also consider whether you actually need to grant the user ALL permissions or whether they could do with less.
The user who originally created the SQL view or procedure has been deleted. If you recreate that user, it should address your error.
Follow these steps:
Go to PHPMyAdmin
Select Your Database
Select your table
On the top menu Click on 'Triggers'
Click on 'Edit' to edit trigger
Change definer from [user#localhost] to root#localhost
Hope it helps
I got the same error after updating mysql.
The error has been fixed after this command:
mysql_upgrade -u root
mysql_upgrade should be executed each time you upgrade MySQL. It
checks all tables in all databases for incompatibilities with the
current version of MySQL Server. If a table is found to have a
possible incompatibility, it is checked. If any problems are found,
the table is repaired. mysql_upgrade also upgrades the system tables
so that you can take advantage of new privileges or capabilities that
might have been added.
Create the deleted user like this :
mysql> create user 'web2vi';
or
mysql> create user 'web2vi'#'%';
If the user exists, then:
mysql> flush privileges;
Solution is just a single line query as below :
grant all on *.* to 'ROOT'#'%' identified by 'PASSWORD' with grant option;
Replace ROOT with your mysql user name.
Replace PASSWORD with your mysql password.
Fixed by running this following comments.
grant all on *.* to 'web2vi'#'%' identified by 'root' with grant option;
FLUSH PRIVILEGES;
if you are getting some_other instead of web2vi then you have to change the name accordingly.
For future googlers: I got a similar message trying to update a table in a database that contained no views. After some digging, it turned out I had imported triggers on that table, and those were the things defined by the non-existant user. Dropping the triggers solved the problem.
quick fix to work around and dump the file:
mysqldump --single-transaction -u root -p xyz_live_db > xyz_live_db_bkup110116.sql
grant all on *.* to 'username'#'%' identified by 'password' with grant option;
example:
grant all on *.* to 'web2vi'#'%' identified by 'password' with grant option;
I had the same problem with root user ans it worked for me when I replaced
root#%
by
root#localhost
So, if the user 'web2vi' is allowed to connect from 'localhost', you can try:
web2vi#localhost
I'm connected remotely to the database.
The user 'web2vi' does not exist on your mysql server.
See http://dev.mysql.com/doc/refman/5.1/en/error-messages-server.html#error_er_no_such_user
If that user does exist, check what servers it can access from, although I would have thought that would be a different error (EG you might have web2vi#localhost, but you are accessing the db as web2vi#% (At anything)
This happened to me after moving the DB from one server to another server. Initially, the definer was using localhost and the user. On the new server we don't have that user, and host had also been changed. I took a back up of that particular table and removed all the triggers manually from phpmyadmin. After that it has been working fine for me.
Why am I getting that error? How do I fix it?
I spent a hour before found a decision for a problem like this. But, in my case, I ran this:
mysql> UPDATE `users` SET `somefield` = 1 WHERE `user_id` = 2;
ERROR 1449 (HY000): The user specified as a definer ('root'#'%') does not exist
If you really want to find the problem, just run this commands one by one:
SHOW PROCEDURE STATUS;
SHOW FUNCTION STATUS;
SHOW TRIGGERS;
SHOW FULL TABLES IN database_name WHERE TABLE_TYPE LIKE 'VIEW';
...and, after each of them, look for the field 'definer'.
In my case it was bearded old trigger, that somebody of developers forgot to delete.
My 5 cents.
I had same error while I tried to select from a view.
However problem appears to be that this view, selected from another view that was restored from backup from different server.
and in fact, YES, user was invalid, but was not obvious where to from the first look.
I had your very same problem minutes ago, I ran into this issue after deleting an unused user from mysql.user table, but doing an alter view fixed it, here is a handy command that makes it very simple:
SELECT CONCAT("ALTER DEFINER=`youruser`#`host` VIEW ",
table_name," AS ", view_definition,";") FROM
information_schema.views WHERE table_schema='databasename'
Mix this with the mysql command line (assuming *nix, not familiar with windows):
> echo above_query | mysql -uuser -p > alterView.sql
> mysql -uuser -ppass databasename < alterView.sql
Note: the command generates and extra SELECT CONCAT on the file, making mysql -uuser -ppass databasename < alterView.sql fail if you don't remove it.
Source: https://dba.stackexchange.com/questions/4129/modify-definer-on-many-views
Try to set your procedure as
SECURITY INVOKER
Mysql default sets procedures security as "DEFINER" (CREATOR OF).. you must set the security to the "invoker".
From MySQL reference of CREATE VIEW:
The DEFINER and SQL SECURITY clauses specify the security context to be used when checking access privileges at view invocation time.
This user must exist and is always better to use 'localhost' as hostname. So I think that if you check that the user exists and change it to 'localhost' on create view you won't have this error.
Your view, "view_quotes" may have been copied from a different database where "web2vi" is a valid user into a database where "web2vi" is not a valid user.
Either add the "web2vi" user to the database or alter the view (normally removing the DEFINER='web2vi'#'%' part and executing the script will do the trick)
In my case, the table had a trigger with a DEFINER user that didn't exist.
You can change the definer for a specific database to an existing user:
UPDATE mysql.proc SET definer = 'existing_user#localhost' WHERE db = 'database_name';
The problem is clear - MySQL cannot find user specified as the definer.
I encountered this problem after synchronizing database model from development server, applying it to localhost, making changes to the model and then reapplying it to localhost. Apparently there was a view (I modified) defined and so I couldn't update my local version.
How to fix (easily):
Note: it involves deleting so it works just fine for views but make sure you have data backed-up if you try this on tables.
Login to database as root (or whatever has enough power to make changes).
Delete view, table or whatever you are having trouble with.
Synchronize your new model - it will not complain about something that does not exist now. You may want to remove SQL SECURITY DEFINER part from the item definition you had problems with.
P.S. This is neither a proper nor best-all-around fix. I just posted it as a possible (and very simple) solution.
You can try this:
$ mysql -u root -p
> grant all privileges on *.* to `root`#`%` identified by 'password';
> flush privileges;
For me, removing the '' from the DEFINER did the trick.
DEFINER = user#localhost
Go into the edit routine section and and at the bottom, change Security Type from Definer to Invoker.
One or several of your views where created/registered by another user. You'll have to check the owner of the view and:
Recreate the user; as the other answers say.
or
Recreate the views that where created by the user 'web2vi' using ALTER VIEW
I had this problem once.
I was trying to migrate views, from BD1 to BD2, using SQLYog. SQLYog recreated the views in the other DataBase (DB2), but it kept the user of BD1 (they where different). Later I realized that the views I was using in my query were having the same error as you, even when I wasn't creating any view.
Hope this help.
If this is a stored procedure, you can do:
UPDATE `mysql`.`proc` SET definer = 'YournewDefiner' WHERE definer='OldDefinerShownBefore'
But this is not advised.
For me, better solution is to create the definer:
create user 'myuser' identified by 'mypass';
grant all on `mytable`.* to 'myuser' identified by 'mypass';
when mysql.proc is empty, but system always notice "user#192.168.%" for table_name no exist,you just root in mysql command line and type:
CHECK TABLE `database`.`table_name` QUICK FAST MEDIUM CHANGED;
flush privileges;
over!
in my case I had a trigger on that table that I could not update data getting the same error.
MySQL error 1449: The user specified as a definer does not exist
the solution was to delete the triggers on that table and recreate them again, this fixed the issue, since the the trigger was made with another user from another server, and the user name changed on the new server after changing hosting company . that's my 2 cents