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.
Related
I've a Galera Cluster Installation with three nodes. As requirement my MariaDB installation must be in different path that default, and user cannot be mysql. So I've moved all mysql data path and I've created a new user and group to manage the mysql service.
MariaDB service is working fine, but I've noticed that a mysql-slow.log has been created with permissions to mysql:root for a third program installation that monitor queries. Opening mysql.err I've found the following error:
[ERROR] Could not use mysql-slow.log for logging (error 13).Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
So I've made chown myuser:mygroup mysql-slow.log and restart the service, but there still having same permissions. Then I've set in my.cnf the slow_query_log=1, in order to try that the myuser create the file at start, but the wrong permission still there also after remove the files and restart.
All the files, in my mariadb data path, are not managed by mysql:mysql user, in my installation are managed by myuser:mygroup so when the mysql-slow.log is created the permissions mysql:root are assigned so I have not permission to write there with myuser:mygroup and if I assign them manually there is not effect because are override with mysql:root after mysql restart.
Somebody knows if there are any way to set by default the user and group owners of the mysql-slow.log file when created?
Thanks.
Regards,
Sergio
Fix the permissions:
chmod 666 mysql-slow.log
See what your script is doing; perhaps it needs fixing, too.
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.
After upgading MySQL to newer version I have error when I want to connect to server:
ERROR 1524 (HY000): Plugin '0' is not loaded
Any ideas?
This looks like a Bug in MySQL as Bug #60432
Modifying mysql.user table can deny users from logging in . Which states that:
If database manager accidentally (or deliberately) modifies mysql.user
table by adding any column in position lower (or equal) than
"max_user_connections", then after reloading privileges no one is
allowed to log in.
Workaround: Undoing the modification made in user table.
Run following commands
sudo /etc/init.d/mysql stop
sudo mkdir -p /var/run/mysqld; sudo chown mysql /var/run/mysqld
sudo mysqld_safe --skip-grant-tables &
and then press enter
now your password get reset, you can change your password again
This works for me
This is indeed a bug with MySQL and a changed user table structure. Unfortunately, if you don't know what changed, you can't change it back. Also, if you cannot login, you cannot fix anything either.
I fixed this as follows. Please be careful with these instructions as they may not work entirely for your setup and you could lose your data if this goes wrong. Don't blame me if it does!
1. Back-up old data dir
Back-up your old data dir somewhere. This allows you to restore the tables at the end. To find out where your data dir is, you can try to initialise mysql. It will give you an error because the data dir already exists:
mysqld initialize
Output:
mysqld: Can't create directory '/usr/local/mysql/data/' (Errcode: 13 - Permission denied)
Now backup your data dir somewhere:
cp -r /usr/local/mysql/data ~/backup-dir/
2. Re-initialize MySQL
With your data dir safely backed up, remove it and re-initialize mysql. It will give you a new temporary password which you can change later.
rm -rf /usr/local/mysql/data
mysqld initialise
The output will give you a new password for 'root'. If you get permission errors, use sudo (not sure about the drawbacks).
Start the server using mysqld_safe to be sure it works the first time:
mysqld_safe
Optionally, change the root password by logging in to mysql and running alter table:
mysql -u root -p
<enter password>
ALTER USER 'root'#'localhost' IDENTIFIED BY 'New Password';
3.Restore data
Stop the mysql server
mysqld stop
Copy all the backup files to the new data dir (run this for every db you need to restore):
cp -r ~/backup-dir/data/<dbname> /usr/local/mysql/data/
For MyISAM tables, this is enough. If you have InnoDB tables, you also need to copy the InnoDB table space from your backup:
cp ~/backup-dir/data/ibdata* /usr/local/mysql/data/
Then, fix permissions (look at the files already present in /usr/local/mysql/data for the right permissions, mine were 'mysql' for both user and group):
chown -R mysql:mysql /usr/local/mysql/data/*
Start the mysql server
mysqld start
All done! You should be able to login again and your tables should be back containing all data, too.
I found a way to fix this...
change the configuration file --my.cnf (usually in /etc/my.cnf)
add "skip-grant-tables" below [mysqld]
now you can login the mysql! backup your database and re-install mysql
I think this will completely repair the problems.
(Plugin 0 is not loaded, i found i cant backup the database then..so you need to add something in mysql.cnf)
I restarted my MySql server and Apache web server and it worked.
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'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*