Can't find file: './ci/users.frm' (errno: 13)

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 开发者_如何学Gofind 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.