I try to insert some lines from csv file to MySQL database "elevage" by command line. The file is names "animal.csv". Below is my request:
`mysql> LOAD DATA LOCAL INFILE 'F:/MYSQL/animal.csv'
-> INTO TABLE Animal
-> FIELDS TERMINATED BY ';' ENCLOSED BY '"'
-> LINES TERMINATED BY '\r\n'
-> (espece, sexe, date_naissance, nom, commentaires);
and I run into this error message
`ERROR 3948 (42000): Loading local data is disabled; this must be enabled on both the client and server sides`.
Then have used the following code:
`SHOW GLOBAL VARIABLES LIKE 'local_infile'`;
and I found: local_file was "OFF". Then I tried to set it to "ON" using the following code :
`SET GLOBAL local_infile=1;`
Unfortunately, I run into another error message:
`ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation`
Although, when I check the grants for the user "student" in which I'm working:
mysql> SHOW GRANTS FOR CURRENT_USER();
I get:
+--------------------------------------------------------------+
| Grants for student#localhost |
+--------------------------------------------------------------+
| GRANT USAGE ON *.* TO `student`#`localhost` |
| GRANT ALL PRIVILEGES ON `elevage`.* TO `student`#`localhost` |
+--------------------------------------------------------------+
2 rows in set (0.00 sec)
which means that "student" has all the privileges on the database "elevage".
Please advice.
The SYSTEM_VARIABLES_ADMIN privilege (as well as the deprecated SUPER privilege) is not a per-database privilege, but rather a per-server privilege. And, it's an administrators' privilege, not a users' privilege.
Why do you need such privileges to use LOAD DATA? Because that command requires its user to write files directly into the database server machine's file space. So users of that command must be completely trusted by the database server.
To use LOAD DATA LOCAL you'll need to get a server administrator to grant those privileges to you, with something like this:
GRANT SUPER, SYSTEM_VARIABLES_ADMIN ON *.* TO 'student'#'localhost';
If this is a shared server, it seems unlikely that your administrator will grant you this privilege. If it's your own server, you are the administrator, and you can use your root account either to grant your student account the privilege, or use the root account directly to run your LOAD DATA command.
Related
I have a MySQL database in the server. I'd like to insert some data that I have in .csv format. After connecting to remote database, I try to execute below SQL statement.
LOAD DATA LOCAL INFILE '~/Downloads/words.csv'
INTO TABLE word
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 ROWS;
Result is the error:
The used command is not allowed with this MySQL version
After doing some research, I understood that I have to enable local-infile to be able import csv to table. In order to set local-infile to 1 I execute this statement:
SET GLOBAL local_infile = 1;
Result is the error:
ERROR 1227 (42000): Access denied; you need (at least one of) the
SUPER privilege(s) for this operation
And when I try to grant all permissions to remote user with below statement
GRANT ALL PRIVILEGES ON *.* TO username#host;
I get,
You are not allowed to create a user with GRANT
even to I'm logged in as root. What do I need to do?
Create the user before giving it a grant;
CREATE USER username#host IDENTIFIED BY 'some password'
GRANT ALL PRIVILEGES ON *.* TO username#host;
I have a table in a database myDatabase in Amazon RDS. Let it be myTable.
use myDatabase;
SELECT * from myTable INTO OUTFILE 'myFile.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"'LINES
TERMINATED BY '\n';
I get this error
Error Code: 1045. Access denied for user '<<UserName>>'#'%' (using password: YES)
I tried running this command
GRANT USAGE ON *.* TO '<<UserName>>'#'%' IDENTIFIED BY '<<password>>';
flush privileges;
0 row(s) affected, 1 warning(s): 1287 Using GRANT statement to modify existing user's
properties other than privileges is deprecated and will be removed in future release. Use
ALTER USER statement for this operation.
I get this warning.
And
I am not able to export the table into a .CSV file at all.
Any idea on how to solve it ? Any thoughts on the steps which might have gone wrong ?
Make sure your user has the FILE privilege.
FILE
Affects the following operations and server behaviors:
Enables reading and writing files on the server host using the LOAD DATA and SELECT ... INTO OUTFILE statements and the LOAD_FILE()
function. A user who has the FILE privilege can read any file on the
server host that is either world-readable or readable by the MySQL
server. (This implies the user can read any file in any database
directory, because the server can access any of those files.)
Enables creating new files in any directory where the MySQL server has write access. This includes the server's data directory containing
the files that implement the privilege tables.
manual entry
I have a mysql grants problem I can't work out.
mysql> UPDATE frontier_remote.trident_update SET completed=NOW() WHERE mac_address="00:1b:24:a0:da:e9" AND completed IS NULL;
ERROR 1143 (42000): SELECT command denied to user 'trident_client'#'host-78-147-8-82.as13285.net' for column 'mac_address' in table 'trident_update'
mysql> SELECT mac_address from trident_update WHERE mac_address="00:1b:24:a0:da:e9" and completed is NULL;
+-------------------+
| mac_address |
+-------------------+
| 00:0:de:ad:be:ef |
+-------------------+
1 row in set (0.04 sec)
So the update claims to fail in the select, but the select part of the command seems to work on its own.
The relevant entries in the grants table look like this:
GRANT USAGE ON *.* TO 'trident_client'#'%' IDENTIFIED BY PASSWORD 'shadow_password'
GRANT INSERT, UPDATE ON `frontier_remote`.* TO 'trident_client'#'%'
GRANT SELECT ON `frontier_test`.`trident_update` TO 'trident_client'#'%'
Any ideas what is going on?
Execute the following command:
FLUSH PRIVILEGES
Reloads the privileges from the grant tables in the mysql database. On
Unix, this also occurs if the server receives a SIGHUP signal.
The server caches information in memory as a result of GRANT, CREATE
USER, CREATE SERVER, and INSTALL PLUGIN statements. This memory is not
released by the corresponding REVOKE, DROP USER, DROP SERVER, and
UNINSTALL PLUGIN statements, so for a server that executes many
instances of the statements that cause caching, there will be an
increase in memory use. This cached memory can be freed with FLUSH
PRIVILEGES.
Documentation: FLUSH
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 am running into a permission error when trying to load data from a flat file database dump into a new table. I know that the schema of the file and my table is the same and I tried tweaking the permissions. What else should I try?
mysql> load data infile 'myfile.txt' into table mytable fields terminated by ',' enclosed by '"';
ERROR 1045 (28000): Access denied for user 'user'#'%'
grant all on mytable.* to 'user'#'%
Here's a thread on the MySQL forums that discusses exactly this.
Here's the answer, posted by Ken Tassell
Problem resolved using the command below:
grant file on *.* to kentest#localhost identified by 'kentest1';
You might have MySQL privileges on the destination table, but you also need the FILE privilege to execute LOAD DATA, and of course the MySQL Server process needs operating-system privileges to the data file too.