我几天前一直在殴打这个人。 我们有一个为期两周的生产mysql数据目录（即实际的二进制文件，而不是sql转储）的每日备份快照，我需要从一个备份恢复表，以便我们可以将其与我们现在有的。
所以我创build了一个dummy schema目录，并提取了相关的表文件（.MYI，.MYD和.frm）并重新启动了mysql。 它显示了，我可以“显示表”，但是如果我尝试以任何方式与它交互（“desc表名”，“select…”等），我得到：
找不到文件：'./schema_name/table_name.frm'（errno：13）
[编辑：实名清理]
Errno 13是权限，所以我仔细检查了一切。 目录和文件具有与所有其他模式相同的所有者和组（mysql：mysql）。 他们也有相同的烫发（目录700，文件660）。 看着“ls -n”，uid也正好匹配。
最近我试着做一个完全不同的备份提取，然后将其链接到MySQL数据目录（没有足够的空间来提取完整的东西），我得到了同样的错误。 我也试着将my.cnf中的mysql数据目录指向备份并重新启动的目录。 它build立了需要在那里的MySQL表，但我仍然有相同的错误。
我可以通过googlesearch到的唯一的东西是因为实际的所有权或许可错误而出现这个问题的人，这似乎并不适合我。 我也发现了一些关于UMASK envvariables的说法，可能会导致这个错误，但我认为这与新安装有关，但这不是。
你正在运行像selinux或其他类似的软件包？ 我build议禁用（或修改安全策略），看看是否有什么阻止MySQL能够访问文件。
如果是这样，请检查系统日志，看看selinux阻止mysql做任何事情。 如果是SELinux，我被告知可能会禁用它，以便您可以testing这个理论。
/usr/sbin/setenforce Permissive 在这种情况下strace是你的朋友。 find你的mysql的进程ID，然后运行：
strace -efile -f -o /tmp/mysql.log -p $ pid
在另一个窗口中做一些导致错误的东西。 你可以按ctrl-c来杀死strace。 如果你看看/tmp/mysql.log你应该看看是什么导致了这个问题。
另外，我真的build议你不要依赖复制二进制数据文件。 SQL转储更加可靠和灵活。 另外，它会出现你正在使用MyISAM。 我真的build议不要使用这些，除非你不关心他们的数据。 InnoDB比MyISAM有许多优势。
我最近有这个问题，我通过更改位于/var/lib/mysql中的数据库目录的每个人的数据库目录权限来解决此问题，如下所示：
PWD: /var/lib/mysql chmod u+x schema_db1 chmod u+x schema_db2 chmod u+x schema_db3 chmod u+x schema_db4
重新启动MySQL引擎，并重新工作！ 我希望这可以为你工作。
当我遇到这个问题之前，这是因为这些文件不是由MySQL用户拥有，无论他们的权限。 chmod 777是不是真的想要在服务器编辑的数据目录上运行。
检查/etc/my.cnfconfiguration的用户名是什么
[mysqld] bind-address=<IP Address> datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=<username>
可能是root或者你已经configuration的。 我修改为根 ，它开始为我工作。
然后启动mysql
service mysqld stop service mysqld start