【问题标题】：Mysql won't start - ibdata1 corrupt? - operating system error number 13 - permissions issueMysql 无法启动 - ibdata1 损坏？ - 操作系统错误编号 13 - 权限问题
【发布时间】：2011-04-23 21:18:24
【问题描述】：

服务器因电源故障而关闭。
Mysql 现在不会启动。
磁盘未满。系统日志如下

Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31  InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.

【问题讨论】：

我假设已检查 ibdata1 的权限？我认为在 debian 及其衍生产品的 /var/lib/mysql 中
是的，一切都没有改变。权限归mysql所有。该文件必须已损坏。这是我目前唯一能想到的。

标签： mysql file permissions innodb

【解决方案1】：

如果您使用 SEL Linux

安装管理

yum whatprovides /usr/sbin/semanage 你得到policycoreutils-python-2.5-22.el7.x86_64

查看 mysqld 安全上下文

安装yum install policycoreutils-python 后，你可以看看mysqld 有什么不同的安全上下文。

semanage fcontext -l | grep mysqld
/etc/mysql(/.*)?                       all files    system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)?                  all files    system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.*                       regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files    system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)?                  all files    system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)?                 all file     system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)?                 all files    system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)?                regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.*         regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.*       regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.*      regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf                           regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf                        regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd                         regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld                    regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe                   regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade                 regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld              regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock             socket       system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper    regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf                  regular file unconfined_u:object_r:mysqld_home_t:s0

在这里你可以看到 mysqld 的所有上下文，一个带有解释的简短列表

mysqld_etc_t - 配置文件
mysqld_db_t - 数据数据库文件
mysqld_log_t - 日志文件
mysqld_exec_t - 执行文件

因此，如果您的文件有错误的安全上下文，您将获得权限被拒绝（错误 13）

解决方案

chcon -R -u system_u -t mysqld_db_t  /var/lib/mysql

但也要检查“正常”权限。我对centos 有这个问题。您必须 systemctl restart mysql 进行更改。

【讨论】：

【解决方案2】：

我遇到了同样的问题，按照以下步骤解决

工作目录/var/lib/mysql

之前的 /var/lib/mysql 由某个未知用户拥有

改成mysql

mysql]# chown -R mysql:mysql *

mysql]# service mariadb start

Redirecting to /bin/systemctl start mariadb.service

像魅力一样工作

【讨论】：

【解决方案3】：

如果您使用的是 ubuntu 或 apparmor，则应允许在 apparmor 中进行此更改。

编辑/etc/apparmor.d/usr.sbin.mysqld 并将/var/lib/mysql 更改为新的DATADIR。

它应该可以工作。

【讨论】：

+1，我错过了这个文件中新目录的结尾 /。
谢谢。 apparmor conf 中的目录可能不是符号链接，还需要命令“service apparmor restart”。
遇到了和作者一样的问题，但是用的是CentOS。这个答案救了我。禁用 selinux 解决了这个问题。
Ubuntu 13.10，拯救了我的一天。没有安装 SELinux，但有 apparmor。谢谢！
我看不出这个答案与这个问题有什么关系：什么是新的 DATADIR ？你在说什么变化？答案是关于重启 - 没有变化？

【解决方案4】：

当我弹出这个问题时，我在/etc/mysql/my.cnf 配置文件中找到了答案。 datadir 行没有指向/var/lib/mysql 目录（数据库所在的位置）。一旦我把这个路径放进去，服务器重启就没有问题了。

【讨论】：

【解决方案5】：

简而言之，（尤其是在 RHEL/CentOS/Fedora 上）试试

getenforce

如果它回复Enforcing，则说明您已启动并运行 SELinux。使用setenforce 0 暂时停用它，看看 MariaDB 现在是否启动！相当常见，尤其是在 RHEL/CentOS/Fedora 上。

还有更多关于这方面的内容，以及this official article。

一般

在 UNIX 环境中，除了用户访问权限之外，还有更多的东西可能会阻止文件访问。

像 SELinux（见上文）或 AppArmor（如 Dan 所述）这样的安全模块可能会禁止它
可以为所需的文件/目录专门设置访问控制列表 (ACL)
任何父文件夹都可以归其他用户所有，并且没有为其他用户设置 x (="dir access")

此外，可能还有其他意想不到的因素，例如 ...

mysql datadir 被设置到 mysql 没有权限的地方（见/etc/my.cnf）
Mysql 可能（奇怪地）以不同的用户身份运行，或者该文件可能只是由其他人拥有

只是提一下我脑海中的想法（顺便说一句，随意编辑/添加到这个答案中）。

在这种情况下，SELinux 是“问题”

对于永久解决方案，您可以尝试恢复适当的安全上下文，...

restorecon -R /var/lib/mysql/

...或者只是停用 SELinux（但在这样做之前先考虑一下），方法是编辑配置（通常在 /etc/selinux/config 中）并按照以下文章中的建议设置 SELINUX=disabled。

这里是来自 mariadb.com 的官方帮助页面：What to do if MariaDB doesn't start
这里有一些来自 redhat.com：MariaDB Changing Database Location

显然这些同样适用于 MySQL。

【讨论】：

【解决方案6】：

请检查：

chown -R mysql:mysql /var/lib/mysql

【讨论】：

在使用 macports 安装的 OS X 上，用户是 _mysql，目录是 /opt/local/var/db/mysql5/，但这似乎工作正常，非常感谢。
这对我来说非常有效。当我在使用 /var/www 文件夹以授予客户端访问他的应用程序文件夹的权限时，我发生了错误。

【解决方案7】：

如果您在 Synology NAS 上遇到此问题，您可以按照 Synology 支持团队的建议进行修复：

尊敬的用户，

这已被确认为已知问题，我们将尝试在以后的 MariaDB 版本中修复此问题。很抱歉给您带来不便。

这里是解决方法：

请尝试使用“root”帐户和密码（与管理员相同）远程登录到您的 DS

运行命令“echo 1 > /var/services/mysql/VERSION”

从 DSM 打开 MariaDB 包将再次触发更新

输入数据库密码并点击更新将解决此问题

更多信息：Synology forum

【讨论】：

【解决方案8】：

在我的情况下是 Selinux 的问题。而
chcon -R --type=mysql_db_t /new/mysql/dir 出现错误：
chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.
所以我使用命令：chcon -R root:object_r:mysqld_db_t /new/mysql/dir.

【讨论】：

【解决方案9】：

我在 CentOS 机器上遇到了完全相同的问题。移动 mysql 数据目录后，我无法再启动该服务，即使我复制了具有相同所有者和权限的文件。

我遇到了 SELinux 安全上下文的问题。如果你运行你的 CentOS 股票，它很有可能被启用，并且不会让你对 MySQL 做你想做的事。要解决这个问题：

ls -Z /var/lib/mysql

和

ls -Z /new/mysql/dir

如果您发现任何差异，则可能是您的问题。要修改这个：

chcon -R --type=mysql_db_t /new/mysql/dir

-R 开关用于递归。如果您只需要更改一个文件，您可以省略它。

【讨论】：

【解决方案10】：

我在我的 CentOS 机器上遇到了完全相同的问题。移动 mysql 数据目录后，我无法再启动该服务，即使我复制了具有相同所有者和权限的文件。

我遇到了 SELinux 安全上下文的问题。如果你运行你的 CentOS 股票，它很有可能被启用，并且不会让你对 MySQL 做你想做的事。要解决这个问题：

ls -Z /var/lib/mysql

和

ls -Z /new/mysql/dir

如果您发现任何差异，则可能是您的问题。要修改这个：

chcon -R --type=mysql_db_t /new/mysql/dir

-R 开关用于递归。如果您只需要更改一个文件，您可以省略它。如果您的上下文与我的不同（可能是不同的发行版），请使用第一个输出所指示的上下文（它应该是 SELinux 内容的第三个字段）

ls -Z /var/lib/mysql

【讨论】：

在我运行chcon -R --type=mysql_db_t /var/lib/mysql 之后，我得到了一堆chcon: can't apply partial context to unlabeled file 'xxxxxx'。这是什么意思？

【解决方案11】：

对我来说，恢复安全上下文 (selinux) 可以解决问题

restorecon -R /var/lib/mysql/

【讨论】：

我创建了一个新分区并将/var/lib/mysql 挂载到它。在我尝试这个之前它不会起作用。有点道理，我猜？

【解决方案12】：

错误：

101130 14:42:51 来自 pid 文件 /var/run/mysqld/mysqld.pid 的 mysqld_safe mysqld 结束 101130 18:07:58 mysqld_safe 使用 /var/lib/mysql 中的数据库启动 mysqld 守护进程 101130 18:07:58 InnoDB：文件操作中的操作系统错误号 13。 InnoDB：错误意味着mysqld没有访问权限 InnoDB：目录。 InnoDB：文件名 ./ibdata1 InnoDB：文件操作调用：“打开”。 InnoDB：无法继续操作。

解决方案 SeLinux SeLinux 安全性：

[root@localhost ~]# service mysqld 重启确定 mysqld：[确定] 开始 mysqld: [ FALLÓ ] [root@localhost ~]# restorecon -R /var/lib/mysql/ [root@localhost ~]# service mysqld 重启确定 mysqld：[确定] 开始 mysqld：[确定] [root@localhost ~]#

【讨论】：

我刚刚在机器上禁用了 selinux，问题就消失了。感谢您为我指明正确的方向！

【解决方案13】：

文件没有损坏。您可以使用“perror”找出这些错误的来源。即

toaster:~ morgo$ perror 13
OS error code  13:  Permission denied

InnoDB 具有损坏检测（页面校验和），并且会很高兴地告诉您这是否是问题所在。

目录权限已更改，或者您的 my.cnf 文件已被破坏，并且它正在尝试在其他地方重新创建数据文件。

【讨论】：

它更可能是一个不正确的用户/组，而不是 r/w。来自官方的 INSTALL-BINARY: shell> chown -R mysql 。外壳> chgrp -R mysql 。 shell> scripts/mysql_install_db --user=mysql # 去掉这一步。壳> chown -R 根。 shell> chown -R mysql 数据
这不是解决方案

【解决方案14】：

我遇到了同样的问题。做了很多研究并找到了这个解决方案。您需要在 ibdata1 上运行此命令 sudo shadowprotect -u root |根

我不知道这是做什么的.. 但它对我有用。

祝你好运。

【讨论】：

当您不知道它们的作用时，您应该避免添加解决方案。您可能会要求人们执行导致系统损坏的操作。