I'm having issues creating a table for my ruby on rails app. It's driving me crazy! The following is returned when I try to create the table:
ERROR 1 (HY000): Can't create/write to file '/usr/local/mysql/data/test_development/users.MYI' (Errcode: 2)
It's worth mentioning I'm a total newbie, btw.
This forum post seems to deal with the same problem:
Try the following:
mkdir /var/lib/mysql/tmp
chown mysql:mysql /var/lib/mysql/tmp
Add the following line into the [mysqld] section: tmpdir =
/var/lib/mysql/tmp
Restart the server
I hope you got this resolved as it has been a year. But I just ran into this same problem and resolved it successfully. This error is because mysql does not have permission to modify files in /usr/local/mysql/data. To bypass using this directory, this was to copy out one of the provided cnf in /usr/local/mysql/support-files into ~/.my.cnf. I used my-medium.cnf. Then I added the variable tmpdir=/tmp under the section [mysqld]. I picked /tmp because I have read and write permissions there. Remember to start and restart your mysql server.
I got this error in Windows, and I find out that I rename my DB name similarly. it solved my problem. Hope this helps.
No need to restart the server
The following can work, and is worth a try:
Using root privileges, search /tmp for a file named like #sql_d5_0.MYD
If found, just move or delete is. That way you release the lock that keeps mysql from accesing your data. It´s
sudo rm /tmp/\#sql*
Related
I've been struggling for a couple of days with this now and have been trying to use this thread amongst other google searches to resolve it but can't seem to get it to work.
When I run this SELECT query (Ubuntu Server 15.10 & MySQL 5.6)...
SELECT column1 ,column2
FROM table
INTO OUTFILE '/home/user/mysql_temp/file.csv';
I get this permission error...
ERROR 1 (HY000): Can't create/write to file '/home/mysql_temp/file.csv' (Errcode: 13 - Permission denied)
From my searching, I understand this to be a system permissions issue rather than a MySQL problem but I can't seem to find a solution which fixes it for me.
Checking apparmor shows that mysqld IS in enforce mode...
apparmor module is loaded.
6 profiles are loaded.
6 profiles are in enforce mode.
/sbin/dhclient
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/sbin/mysqld
/usr/sbin/tcpdump
0 profiles are in complain mode.
2 processes have profiles defined.
2 processes are in enforce mode.
/sbin/dhclient (676)
/usr/sbin/mysqld (1285)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
So I edited /etc/apparmor.d/usr.sbin.mysqld and added the following lines and then restarted apparmor...
/home/user/mysql_temp/ rw,
/home/user/mysql_temp/* rw,
I also changed the owner:group of mysql_temp to mysql and gave it full permissions...
sudo chown mysql:mysql mysql_temp
...
drwxrwxrwx 2 mysql mysql 6 Apr 1 22:02 mysql_temp
After this, I still receive the same error.
Have I missed something? Misunderstood some of the instruction? Would be grateful for advice. Thanks.
What worked for me was accessing the my.ini file. Within that file, look for "Secure File Priv." There should be a file path which is the secure route mySql gives permissions to output the designated file. I hope this helps! For me, the file was under C:/ProgramData/mysql/mysql Server 5.7
Solution Based On; Ubuntu 20.10 with Apparmor active and MySql 8
Solution Summary and Lesson Learned:
Unless you have a damn good reason not to
Leave the default secure-file-priv settings alone,
Give your user(s) FILE privileges in mysql,
And tell apparmor to allow writing to the default directory set up by the mysql installer.
The default configuration set secure-files-priv to /var/lib/mysql-files. Left as it was, I was able to import files by placing them in that directory so long as I gave the user file privileges like so, GRANT FILE ON *.* TO myuser#host;
However, when I tried to write to that directory I got the dreaded Error Code: 1. Can't create/write to file '/var/lib/mysql-files/select_out.csv' (OS errno 13 - Permission denied). I could have solved this very easily by editing /etc/apparmor.d/usr.sbin.mysqld and changing
# Allow data files dir access
/var/lib/mysql-files/ r,
/var/lib/mysql-files/** rwk,
to
# Allow data files dir access
/var/lib/mysql-files/ rw,
/var/lib/mysql-files/** rwk,
But I didn't know about apparmor at the time, and so I fumbled around screwing up more stuff until I found #spcurtis81's post. If that's what happened to you, read on, maybe you can learn something from my journey.
Unfortunately at some point - and god only knows why - I decided to move the secure-file-priv directory to /mysql-files. This created a lot more work for me. If nothing else it taught me a lot, and gave me the opportunity to share.
I had to change the 'secure-files-priv' setting under [mysqld] section in one of .cnf files, but which, there are so damn many. I found it by doing this,
cd /
find . -name "*.cnf" -printf '%p\n' -exec grep "\[mysqld\]" {} \;
and getting
./conf.d/mysqldump.cnf
./conf.d/mysql.cnf
./my.cnf
./debian.cnf
./mysql.conf.d/mysqld.cnf
[mysqld]
./mysql.conf.d/mysql.cnf
./mysql.cnf
so the file above the [mysqld] was the one for me. I found several references to modifying my.cnf but as it didn't already have the section in it, I went with mysqld.cnf. I also reckoned that the mysqld.cnf was for the server daemon as opposed to the user program. It worked, so it aint stupid, but perhaps a more knowledgeable person could explain the hierarchy of .cnf files.
There was no existing secure-files-priv entry for this setting so I found what seemed to be a reasonable location for it and added the following.
# Added 12/13/2020 in an attempt to relocate the secure-file-priv directory
secure-file-priv = /mysql-files
No joy. I found another reference that said that you had to specify a temp directory and so I uncommented this line from the same file.
# If MySQL is running as a replication slave, this should be
# changed. Ref https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmpdir
tmpdir = /tmp
Still no joy. Then I found #spcurtis81's post here and learned about the apparmor settings. So in /etc/apparmor.d/usr.sbin.mysqld I changed
# Allow data files dir access
/var/lib/mysql-files/ r,
/var/lib/mysql-files/** rwk,
to
# Allow data files dir access
/mysql-files/ rw,
/mysql-files/** rwk,
AND still no f-ing joy!
The final step that resolved the issue: chmod -R 700 /mysql-files
When I had created the directory I set the owner to mysql and gave it 644 permissions. That seemed reasonable but added an error to my mysql error log: 'Insecure configuration for --secure-file-priv: Location is accessible to all OS users. Consider choosing a different directory.'
I don't like security warnings so I changed the permission to 600, never thinking mysql would need executable rights on a data directory. I was wrong. So, there you go.
It's an directory error where you storing the data.
give the permission to the folder where data is store in your case the data store in the "mysql_temp"
use the command "$ chmod 777 mysql_temp"
Don't forget, you have to reload apparmor.
$ sudo service apparmor reload
If mysqld is included in enforce mode, then the entries can be written in /var/log/messages when AppArmor blocks the writes/accesses.
You can edit /etc/apparmor.d/usr.sbin.mysqld and add /home/user/mysql_temp/ and /home/user/mysql_temp/* near the bottom like this:
/usr/sbin/mysqld {
...
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,
**/home/user/mysql_temp/ r,
/home/user/mysql_temp/* rw,**
}
And then you can make AppArmor reload the profiles.
# sudo /etc/init.d/apparmor reload
WARNING: The above change will allow MySQL to read and write to the /home/user/mysql_temp/ directory.
Change ownership of the specified directory to mysql user.
chown mysql:mysql /data/data-directory
the original question was writing to an outfile here:
INTO OUTFILE '/home/user/mysql_temp/file.csv';
the problem could be a mysql configuration; and not apparmor.
if you are running with systemd, look at this setting in /etc/systemd/system/mysql.service:
# Prevent accessing /home, /root and /run/user
ProtectHome=true
assuming all of the file permissions are correct, one would need to change this to false to write to the /home directory.
I run a WordPress website. Today I found that wp_posts table is crashed. When I tried to repair the table, I got the following error:
REPAIR TABLE wp_posts;
error Can't create new tempfile: './[databasename]/wp_posts.TMD'
repair status Operation failed
I tried to run the following command in shell:
myisamchk -r -f wp_posts.MYI
error: File 'wp_posts.MYI' doesn't exist
Can you please tell me what else I can try to fix this problem?
Turned out that "myisamchk -r -f wp_posts.MYI" was the correct solution. I just had to go to the data folder.
In my CentOS system, I changed directory to /var/lib/mysql/[database]/and found wp_posts.MYI
After removing this file, repair was successful.
Try stopping your service using the following command sudo service mysql stop
Now do the repair check myisamchk -r -f -o /var/lib/mysql/DatabaseName/wp_posts
Start your service and enjoy it!
It works for me
Try adding the following line to your wp-config.php file:
define( 'WP_ALLOW_REPAIR', true );
Then go to:
/wp-admin/maint/repair.php
That should take effect and automatically repair your crashed table.
For mariaDB and some other combination of OS and DB version, the file may also be located under /config/databases/[DATABASE].
Try to run as root (sudo su):
service mysql stop
myisamchk -rf /config/databases/[databasename]/wp_posts.MYI
service mysql start
I just had the same trouble. The problem was the .TMD file already existed and mysqlrepair refused to overwrite it. I removed the .TMD file and the mysqlrepair worked famously. I had to stop the process attempting to use the crashed table, then run the repair.
When I saw this error in phpMyadmin, I got around it by navigating to /var/lib/mysql/[database]/ and deleting the TMD file for the table I was trying to repair (not the MYI file as stated in the explanation above).
When I tried getting rid of the MYI file, the repair operation didn't work.
I want to copy the database tables from my production server to a local test machine so I can perform test om (copies of) the real data.
I stopped mysql and deleted all the frm, MYD and MYI files. Starting mysql here and querying show tables gives an empty result set. I then shut down mysql and copied all the frm, MYD and MYI files from the server. When starting mysql "show tables" shows the tables as expected but trying to query them I get the error message
ERROR 1017 (HY000): Can't find file: './WhateverTableIQuery.frm'
(errno: 13)
But the WhateverTableIQuery.frm file is on the disc and is identical to the one on the server.
Any ideas about what might be the problem?
I'd suggest giving two things a try:
1. Check Permissions
Make sure that your MySQL data directory and all the files in it are owned by mysql user and mysql group. This may not be the case if you copied the files onto your local test machine as root user:
chown -R mysql:mysql your-mysql-data-dir-here
2. Repair corrupted tables
Use mysqlcheck to check for corrupted tables and repair them if it finds any:
mysqlcheck -u root -p --auto-repair --all-databases
If you still can't use the tables after that then give mysqldump a go!
I encountered the same issue after restoring a MySQL database with frm and MYD files. After a number of hours spent I observed that I have configured the database directory with only read and write permission to mysql user but not execute permission. After adding execute permission to the database directory, the problem was solved.
I did have the very same issue a couple minutes ago and it took me a few minutes to realize that I had insufficient permission to access the .sql file I wanted to import.
In order to get rid of this problem you could just move the file to a place you know you have access to (with your current user) for sure. (eg. ~/Home_directory).
I hope I could help some lonely soul that was searching for the answer just like I was.
I had the same issue and did this...
Delete Migrations Folder
Drop the _migrationhistory table
Enable, Add and Update migration
I'm sure there's a much better way to solve this but, it worked for me.
I changed permissions for the mysql-data-directory as well as the <table>.frm file.
If using as root user:
chmod 600 mysql-data-directory chmod 600
mysql-data-directory/tableOfData.frm
If using as non-root user:
chmod 660 mysql-data-directory
chmod 660 mysql-data-directory/tableOfData.frm
This error, "General error: 1017 Can't find file", also happened on Windows with WAMP if the table doesn't exist.
Try following things:
repair whole database
change permission to mysql:mysql
restart mysql service
One of these will work.
I installed LAMP on Ubuntu 11.04 and copy project from Windows.
PHP directory (/ci/) to var/www/
and
MySQL project directory (/ci/) to var/lib/mysql/
Full text of error that i get:
A Database Error Occurred
Error Number: 1017
Can't find file: './ci/users.frm' (errno: 13)
SELECT COUNT(*) AS `numrows` FROM (`users`) WHERE `email` = 'admin#localsite.com'
I googled that its permission problem, but don't know what do next.
Log from /var/log/mysql/error.log:
110622 19:27:21 [ERROR] /usr/sbin/mysqld: Can't find file: './ci/users.frm' (errno: 13)
Permissions problem meaning the permissions on the file. MySQL probably can't read it. Just change the owner and group to mysql and it should work.
chown mysql:mysql /var/lib/mysql/ci/*
As well as the files being readable by the MySQL user, the directory containing the .MYI files needs to be read, write and executable by the MySQL user. On my system this was achieved by:
chown -R mysql:mysql /var/lib/mysql/dbname
chmod -R 660 /var/lib/mysql/dbname
chown mysql:mysql /var/lib/mysql/dbname
chmod 700 /var/lib/mysql/dbname
This is an old topic, but I didn't find anything that worked for me so for anyone running into the same problem, yet the above file permission suggestions still don't change the "Can't find file" errors, here's what worked for me and my particular issue.
I was doing a rescue from one CentOS server to another using a recovery image, which had a different OS than the original OS and the original filesystem was mounted on a temporary dir. While I had access to the original /var/lib/mysql files, I didn't have access to the mysql admin or dump utilities, which requires the server to be running anyway (it's not automatically included when doing a recovery from a read-only image). Backups were a week old and I wanted to see if I could get the most recent data possible.
Changing the standard file permissions on these still kept giving "Can't find file" for nearly all of the database tables, however I could see that the tables were there. Turns out it was related to SELinux context on the files I had moved over using rysnc. All of the rescued dirs and files looked like this:
$ ls -alZ
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_dev
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_local
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_production
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_staging
The -Z flag notes the security context of files and dirs. Notice the unconfined_u and admin_home_t context. These are different from what they should be:
drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
Changing these database files to the proper context solved the problem and gave proper access to mysqld using the chcon command:
$ chcon -R -u system_u -t mysqld_db_t somedb_*
This changed all my custom databases to the proper SELinux context and the files could now be recognized by mysqld. I recommend running the chcon commad while the database server is not active, just as a precaution.
Hope that helps someone running into the same problem I had! Of course, you can turn off SELinux temporarily to test if this is fact this issue, but I didn't want turning off SELinux as a permanent solution.
I followed this steps:
Stop the mysql service.
Modify the my.cnf line datadir to my custom location.
Deleted all the files ib_data* , ib_logfile* in our new custom location
Change the permissions of the entire folder with your sentence:
chown mysql:mysql -R /custom_location/mysql/*
Start again the mysql service.
It works!!
Thanks
This error also occurs if the table is not in the database; so if you changed permissions of the directory and are still running into issues check your database and make sure the table is there.
So let's say you got an error like the OP:
Can't find file: './ci/users.frm'
ci is the database name
users is the table name
So in this case if you changed permissions and still had this issue you would verify that the users table is in the ci database.
#Brent Baisley It does work in XAMPP for Linux, but the location is different.
I did upgrade the Kernel today to fix the new Linux “Dirty Cow” Vulnerability (CVE-2016-5195). After the reboot I got the 'frm' permission error too.
So, if you get the following error:
Can't find file: 'yourtablename.frm' (errno: 13 - Permission denied) SQL query :...
You can do:
chown mysql:mysql /opt/lampp/var/mysql/yourDBname/*.frm
This will resolve your issue.
If you'd like to check, if your permission to any of the files has been modified before you execute the permission change, do:
ls -l /opt/lampp/var/mysql/yourDBname/*.frm
Hope that helps someone.
If you have failed RENAME TABLE statement, it could leave MySQL metadata in bad state. The solution is to recreate schema or to recreate table.
The full error is:
Message: Mysqli statement execute
error : Can't create/write to file
'/var/www/zendApp/backup/mysql/1268733580_name.sql'
(Errcode: 13)
I have tried several things already with the /var/www/ZendApp/backup/mysql directory
$chmod 777 mysql
$chmod 1777 mysql
$chown root:root mysql
$chown mysql:mysql mysql
But nothing helps. What am I doing wrong here? Do I have to tell mysql somewhere that I can write to that directory?
With the help off Dominik # Super User, I discovered that Ubuntu is running apparmor and my server is running on Ubuntu. I quote from wikipedia:
AppArmor allows the system
administrator to associate with each
program a security profile that
restricts the capabilities of that
program
Sure enough, among those programs was mysqld. So not the user or his privileges are the problem, but the restrictions imposed on the process by apparmor. I then found the solution here
sudo touch /etc/apparmod.d/disable/usr.sbin.mysqld
sudo /etc/init.d/apparmor reload
This makes mysqld a free process which for me, on that server, is no problem. So, after days of searching, problem fixed!