Mysql ne démarre pas - ibdata1 corrompu? - erreur du système d'exploitation numéro 13 - problème d'autorisations

De l'arrêt du serveur en cas de panne électrique.

Mysql ne va pas commencer maintenant.

Le disque n'est pas plein.
Syslog est ci-dessous

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.
  • Vérifié les autorisations pour ibdata1 je suppose? Dans /var/lib/mysql sur debian et ses dérivés, je pense
  • Oui, rien n'a changé. Les autorisations sont la propriété de mysql. Le fichier doit être corrompu. C'est la seule chose que je peux penser en ce moment.
InformationsquelleAutor eat_a_lemon | 2010-10-11
  1. 16

    Le fichier n'est pas corrompu. Vous pouvez trouver la source de ces erreurs avec "perror'. c'est à dire

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

    InnoDB a détection de la corruption (page de sommes de contrôle) et serait heureux de vous dire si le problème était là.

    Soit les autorisations de répertoire ont changé, ou votre mon.cnf fichier a été modifié, et c'est en essayant de recréer les fichiers de données à un autre endroit.

    • Ok, alors comment puis-je définir les autorisations correctes pour ce fichier?
    • Il est plus probable qu'un utilisateur incorrect/groupe que r/w. Officiel, INSTALLEZ-BINAIRE: shell> chown -R mysql . shell> chgrp -R mysql . shell> scripts/mysql_install_db --user=mysql # supprimer cette étape. shell> chown-R root . shell> chown -R mysql données
    • ce n'est pas une solution
    InformationsquelleAutor Morgan Tocker
  2. 94

    Si vous utilisez ubuntu ou apparmor vous devrait permettre ce changement de apparmor.

    Modifier /etc/apparmor.d/usr.sbin.mysqld et changement /var/lib/mysql avec la nouvelle DATADIR.

    Il devrait fonctionner.

    • +1, j'avais raté la fin / sur le nouveau répertoire dans ce fichier.
    • Merci. Les répertoires dans apparmor conf peut-être pas les liens symboliques et de commande "service apparmor redémarrer" a également été nécessaire.
    • Eu le même problème que l'auteur, mais à l'aide de CentOS. Cette réponse m'a sauvé. Désactiver selinux a résolu le problème.
    • Ubuntu 13.10, a sauvé ma journée. N'ont pas de SELinux est installé, mais n'ont apparmor. Merci!
    • woooow merci homme.
    • apparmor perdu mon toute la journée.
    • Après l'édition de l'application de l'armure de configuration assurez-vous de redémarrer apparmor pour qu'il prenne effet
    • Je ne vois pas comment cette réponse se rapportent à la question: qu'est-ce que le nouveau DATADIR ? qui sont le changement de u en train de parler? la réponse est un sujet un redémarrage il n'y a pas de changement?
    • Ubuntu 14.04, a sauvé ma journée, trop. Merci beaucoup!
    • J'ai raté la fin slash le nouveau répertoire de données. Merci beaucoup.
    • Regardez /var/log/kernl.log pour voir le fichier d'accès apparmor est bloquant. Ce n'est pas toujours facile de comprendre, par exemple, si vous avez des liens symboliques de sortir de votre /var/lib/mysql dossier. BTW, je pense que le comportement à l'égard des liens symboliques changé de ubuntu 14.04 à 16.04.

    InformationsquelleAutor Dan
  3. 18

    Erreur:

    101130 14:42:51 mysqld_safe mysqld à partir de pid fichier /var/run/mysqld/mysqld.pid terminé 
101130 18:07:58 mysqld_safe Démarrage de mysqld avec des bases de données dans /var/lib/mysql 
101130 18:07:58 InnoDB: erreur du système d'Exploitation numéro 13 dans une opération de fichier. 
InnoDB: L'erreur signifie que mysqld n'a pas les droits d'accès à 
InnoDB: le répertoire. 
InnoDB: nom du Fichier ./ibdata1 
InnoDB: opération de Fichier appel: "ouvrir". 
InnoDB: Impossible de continuer l'opération.

    Solution SeLinux de sécurité SeLinux:

    [root@localhost ~]# service mysqld restart 
Deteniendo mysqld: [ OK ] 
Iniciando mysqld: [ FALLÓ ] 
[root@localhost ~]# restorecon -R /var/lib/mysql/
[root@localhost ~]# service mysqld restart 
Deteniendo mysqld: [ OK ] 
Iniciando mysqld: [ OK ] 
[root@localhost ~]#
    • J'ai juste désactivé selinux à la machine et le problème a disparu. Merci pour de me pointer à droite direction!
    InformationsquelleAutor Carlos Omar Briseño Gutierrez
  4. 13

    Pour moi, la restauration du contexte de sécurité (selinux) a fait le tour

    restorecon -R /var/lib/mysql/

    • J'ai créé une nouvelle partition et monté /var/lib/mysql à elle. Il ne serait pas travailler jusqu'à ce que j'ai essayé ce. Un peu de logique, je suppose?
    InformationsquelleAutor dordal
  5. 9

    veuillez vérifier:

    chown -R mysql:mysql /var/lib/mysql
    • sur OS X installé à l'aide de macports, l'utilisateur a été _mysql et le répertoire /opt/local/var/db/mysql5/, mais cela semble avoir fonctionné, merci beaucoup.
    • Cela a fonctionné parfaitement pour moi. L'erreur s'est produite à moi, pendant que je jouais avec /var/www dossier pour donner au client l'accès à son dossier app.
    InformationsquelleAutor IndikatorDesign
  6. 5

    J'ai eu exactement le même problème sur mon CentOS boîte. Après le déplacement de données mysql répertoire autour de moi, je ne pouvais pas démarrer le service plus, même comme je l'avais copié les fichiers avec le même propriétaire et les permissions.

    J'ai eu un problème avec la sécurité SELinux contexte. Si vous exécutez votre CentOS stock, il a de bonnes chance d'être activé et ne les laissons pas faire ce que vous voulez avec MySQL. Pour résoudre ce problème :

    D'abord comparer l'ancien dir et nouveau répertoire à l'aide de 

    ls -Z /var/lib/mysql

    et 

    ls -Z /new/mysql/dir

    Si vous voir la différence qu'il est susceptible d'être votre problème.
    Pour modifier ce : 

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

    Le commutateur-R est la récursivité. Si vous avez seulement besoin de modifier un fichier, vous pouvez l'omettre.
    Si votre contexte est différente de la mienne(peut-être une autre distro), utilisez celui qui est indiqué par la sortie de la première (ce doit être le 3ème domaine de la SELinux trucs) 

    ls -Z /var/lib/mysql
    • Après j'ai couru chcon -R --type=mysql_db_t /var/lib/mysql, j'ai eu un tas de chcon: can't apply partial context to unlabeled file 'xxxxxx'. Qu'est-ce que cela signifie?
    InformationsquelleAutor A Nun Famous
  7. 4

    En bref, (en particulier sur RHEL/CentOS/Fedora) essayez

    getenforce

    si il répond avec Enforcing vous avez SELinux et en cours d'exécution. Désactiver temporairement avec setenforce 0 et voir si MariaDB commence maintenant! Plutôt communs, en particulier sur RHEL/CentOS/Fedora.

    Il n'y a plus à ce sujet plus bas, ainsi que dans ce fonctionnaire de l'article.

    En général

    Il y a plus de choses dans un environnement UNIX, qui pourrait empêcher l'accès aux fichiers, que de simplement les droits d'accès utilisateur.

    • Modules de sécurité comme SELinux (voir ci-dessus) ou AppArmor (comme mentionné Dan) pourrait rejeter
    • Listes de Contrôle d'accès (ACL) pourrait être définie spécifiquement, pour les fichiers/répertoires
    • Aucun des dossiers parent pourrait être détenue par un autre utilisateur, et n'ont pas de x (="dir accès") pour les autres

    En outre, il pourrait y avoir d'autres facteurs inattendus, comme la ...

    • Mysql datadir être fixé à un endroit, où mysql n'a pas les permissions (voir /etc/my.cnf)
    • Mysql pourrait (étrangement) être en cours d'exécution en tant qu'utilisateur différent, ou le fichier est peut-être tout simplement la propriété de quelqu'un d'autre

    Juste pour mentionner une vue sur les choses du haut de ma tête (n'hésitez pas à modifier/ajouter à cette réponse btw).

    Dans le cas, SELinux est "le problème"

    Pour une solution permanente, vous pouvez essayer de restaurer le contexte de sécurité appropriées, ...

    restorecon -R /var/lib/mysql/

    ... ou tout simplement désactiver SELinux (mais réfléchissez un peu avant de le faire), en éditant le fichier de configuration (généralement dans /etc/selinux/config) et la mise en SELINUX=disabled comme suggéré dans l'article suivant.

    Évidemment ceux-ci sont applicables à MySQL exactement de la même manière.

    InformationsquelleAutor Levit
  8. 3

    J'ai eu le même problème et de le résoudre par les étapes ci-dessous

    De travail répertoire /var/lib/mysql

    Plus tôt /var/lib/mysql a été possédé par certains utilisateurs inconnus

    Changé à mysql

    mysql]# chown -R mysql:mysql *

    mysql]# service mariadb start

    Redirecting to /bin/systemctl start mariadb.service

    Fonctionne comme un charme

    • fonctionne comme un charme 😉
    InformationsquelleAutor Rohit Gupta
  9. 2

    Lorsque cette surgi pour moi, j'ai trouvé la réponse dans le /etc/mysql/my.cnf fichier de configuration. Le datadir ligne n'ont pas de point à la /var/lib/mysql répertoire (où les bases de données). Une fois j'ai mis ce chemin d'accès, le serveur redémarré sans problème.

    InformationsquelleAutor John Creamer
  10. 1

    J'ai eu exactement le même problème sur mon CentOS boîte. Après le déplacement de données mysql répertoire autour de moi, je ne pouvais pas démarrer le service plus, même comme je l'avais copié les fichiers avec le même propriétaire et les permissions.

    J'ai eu un problème avec la sécurité SELinux contexte. Si vous exécutez votre CentOS stock, il a de bonnes chance d'être activé et ne les laissons pas faire ce que vous voulez avec MySQL. Pour résoudre ce problème :

    D'abord comparer l'ancien dir et nouveau répertoire à l'aide de 

    ls -Z /var/lib/mysql

    et 

    ls -Z /new/mysql/dir

    Si vous voir la différence qu'il est susceptible d'être votre problème.
    Pour modifier ce : 

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

    Le commutateur-R est la récursivité. Si vous avez seulement besoin de modifier un fichier, vous pouvez l'omettre.

    InformationsquelleAutor A Nun Famous
  11. 1

    Si vous utilisez du SEL Linux

    Intall semanage

    yum whatprovides /usr/sbin/semanage vous obtenez policycoreutils-python-2.5-22.el7.x86_64

    Voir mysqld contexte de sécurité

    Après l'installation yum install policycoreutils-python vous pouvez juste regarder ce contexte de sécurité différent mysqld a. 

    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

    Ici, vous voyez tout contexte pour mysqld une courte liste avec explication

    1. mysqld_etc_t - fichiers de configuration
    2. mysqld_db_t - données des fichiers db
    3. mysqld_log_t - les fichiers journaux
    4. mysqld_exec_t - exécution des fichiers

    Donc, si vous avez le mauvais contexte de sécurité de vos fichiers, vous obtenez un permission denied (erreur 13)

    Solution

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

    Mais cocher la case "normal" des autorisations, trop. J'ai eu ce problème avec centos. Vous devez systemctl restart mysql pour les modifications.

    InformationsquelleAutor Kordi
  12. 0

    Dans mon siuation est Selinux du problème. Et l'

    chcon -R --type=mysql_db_t /new/mysql/dir vient d'erreur:

    chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.

    J'ai donc utiliser la commande：chcon -R root:object_r:mysqld_db_t /new/mysql/dir.

    InformationsquelleAutor zjhui
  13. 0

    Si vous avez ce problème sur un NAS Synology vous pouvez résoudre le problème en suivant les conseils de l'équipe de support Synology:

    Cher Utilisateur,

    Cela a été confirmé comme un problème connu et nous allons essayer de résoudre ce problème dans les plus MariaDB libération. Désolé pour votre compréhension.

    Voici la solution:

    • S'il vous plaît essayer de telnet à votre DS avec le compte "root" et le mot de passe (le même que admin)
    • exécutez la commande "echo 1 > /var/services/mysql/VERSION"
    • ouvrir MariaDB paquet de DSM va déclencher la mise à jour de
    • type dans la base de données de mot de passe et cliquez sur mise à Jour va résoudre ce problème

    Plus d'infos: Le forum de Synology

    InformationsquelleAutor DarkLite1
  14. -9

    J'ai eu le même problème.
    Fait beaucoup de recherche et a trouvé cette solution.
    Vous devez exécuter cette commande sur ibdata1
    sudo shadowprotect -u root | root

    Je ne sais pas ce que cela fait.. mais il a travaillé pour moi.

    Bonne chance.

    • Vous devriez éviter d'ajouter des solutions quand tu ne sais pas ce qu'ils font. Vous pourriez être en demandant aux gens de réaliser des opérations d'endommager le système.
    InformationsquelleAutor NickMonkey