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)
Related
Goal
My goal is to insert BLOB data into MySQL from various paths - NOT just MySQL server host folder.
Where I am at now
I am able to write a query using load_file() function using this path only - C:\ProgramData\MySQL\MySQL Server 8.0\Uploads
Problem
When using any other paths such as the \Desktop - MySQL values show as NULL.
As the documentation states "To use this function, the file must be located on the server host."
Question
How can I GRANT or enable privilege to use load_file() for any path?
Root Grant Privileges
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE ON *.* TO "root"#"%" WITH GRANT OPTION
EDIT:
Got something out of here: https://stackoverflow.com/a/42410342/12485722
"If you need to change the path, you must do it in the my.ini file:"
" Secure File Priv.
secure-file-priv="V:/NEW/PATH/TO/MySQL Server/Files" "
How can I add multiple paths in the .ini file?
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 am using mysql-server 5.5.41-0+wheezy1 on Debian 3.2.54-2 x86_64
I have problems (not related to mysql) on some on my web app that uses mysql table so I am doing a re-install of the app
I started with aptitude remove packagename to remove my app and mysql-server, but it seems that it did not remove/delete the currently used mysql databases
When I reinstall mysql-server the previous database still used. I drop the previous user to create a new one using the command drop user olduser and also I drop the old database drop database olddb
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
+--------------------+
Now when I recreate the database with new name, it is a sucess, but if I recreate the same old user create user 'olduser'#'localhost' identified by 'somesecret'; it will always say ERROR 1396 (HY000): Operation CREATE USER failed for 'olduser'#'localhost' Creating a different user is a success, but this problem of recreating the same old user is bugging me. Is there something wrong or something I missed?
I have tried flush privileges
Well it's kinda hard to debug this without having any access to the database, this error is common with MySQL, but normally a FLUSH PRIVILEGES fix it. Anyway, if really the user is dropped you can bypass it that way :
CREATE USER 'anyuser'#'localhost' IDENTIFIED BY 'test123';
UPDATE mysql.user SET USER='olduser' WHERE USER='anyuser';
Note that to completly remove an user, you must delete all datas associated to it in these tables : columns_priv, db, procs_priv, tables_priv. Then finally execute flush privileges.
From the doc :
DROP USER does not automatically drop or invalidate databases or
objects within them that the old user created. This includes stored
programs or views for which the DEFINER attribute names the dropped
user. Attempts to access such objects may produce an error if they
execute in definer security context. (For information about security
context, see Section 18.5, “Access Control for Stored Programs and
Views”.)
I have a MySQL issue which troubles me for long time. Why sometimes a table is able to be SELECT but not able to be UPDATE or INSERT?
Maybe it is the reason of table lock. But I tried "SHOW OPEN TABLES", it doesn't shows table is locked.
Is there any other reason which will cause this problem?
Why sometimes a table is able to be SELECT but not able to be UPDATE
or INSERT?
Most likely because the user you are connecting with does not have UPDATE or INSERT permissions. You can check what GRANTS you have using a command like this in MySQL:
SHOW GRANTS FOR 'user_name'#'localhost';
Be sure to change user_name to the username you are using to connect to the server with. Also be sure localhost matches the host you are connecting to. But that said, MySQL GRANTS can be confusing. For example, I have seen some servers—when I had to clean up someone else’s work—where localhost would not work, but 127.0.0.1 would work so you might need to run the above command like this:
SHOW GRANTS FOR 'user_name'#'127.0.0.1';
And if you need to adjust your GRANTS then you could run this; be sure to change the database_name, user_name, localhost & password to match your setup:
GRANT USAGE ON `database_name`.* TO 'user_name'#'localhost' IDENTIFIED BY 'password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON `database_name`.* TO 'user_name'#'localhost';
The first line GRANT USAGE grants basic usage to the database to the user. The next line grants specific access rights and this is a fairly common stack that allows access to SELECT, UPDATE or INSERT items into the database as well as other sundry items.
That said, based on your comments it seems that this might be an issue where someone—or some code—with access to that database is running a LOCK TABLES statement that would result in the behavior you describe. Tables would be locked while work is done. And then an UNLOCK TABLES would be run afterwards to allow UPDATE and INSERT commands to go through.
If you wish to debug & have server level access you might want to temporarily enable MySQL logging to see what queries are coming through. But remember: Activating the MySQL log is a resource hog & can slow down your server. Only do it during a window when you know you can safely test.
Using an Ubuntu 12.04 serve setup for an example, you would open op the MySQL config file like so:
sudo nano /etc/mysql/my.cnf
Then search for the settings for general_log_file and general_log which should be commented out & look like this:
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1
Uncomment both general_log_file and general_log and then restart MySQL like this:
sudo service mysql restart
Now you can follow the MySQL logs like so with tail:
sudo tail -f -n 200 /var/log/mysql/mysql.log
And if you see LOCK TABLES pop up in there, you know that is the cause. To disable logging just comment out those lines & restart MySQL again.
I have just installed MySQL on Debian 7.0.0.
I successfully imported by database from another system using
mysql -u root -p DBName <mysql27May13.dump
I then successfully logged onto MySQL using
mysql -u root -p
I then successfully selected the database using
use DBName;
Also
show tables;
showed the tables I imported. However, when I try to change the root user name using
update user set user='SomeNewName' where user='root';
I get the error message
ERROR 1146 (42S02): Table 'DBName.user' doesn't exist
If you want to change a MySQL username you should use RENAME USER
RENAME USER root#localhost TO other_user#localhost
The table you want to update -- user, in this case -- is not within your database (which I assume is called DBName, here). The database you need is, in fact, simply called mysql.
You can work around this in a few ways:
Run your update on mysql.user instead of user.
use mysql before you do the update.
Use the supplied RENAME keyword to do the job instead, as #ExplosionPills suggests.
I'd suggest always taking approach #3 for user management unless you know for sure you're trying to do something the built-in commands can't handle. Chances are, you're not -- and if you are, you'll know it.