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

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

ça devrait marcher.

Erreur:

101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101130 18:07:58  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

Solution de 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 ~]#

pour moi, restaurer le contexte de sécurité (selinux) a fait l'affaire

restorecon -R /var/lib/mysql/

s'il vous plaît vérifier:

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

j'ai eu exactement le même problème sur ma boîte de CentOS. Après avoir déplacé le répertoire de données mysql, Je ne pouvais plus démarrer le service, même si j'avais copié les fichiers avec le même propriétaire et les mêmes permissions.

j'ai eu un problème avec le contexte de sécurité SELinux. Si vous lancez votre stock de CentOS il a de bonnes chances d'être activé et ne laissera pas faire ce que vous voulez avec MySQL. Pour résoudre ce problème :

comparez D'abord l'ancien dir et le nouveau dir en utilisant

ls -Z /var/lib/mysql 

et

ls -Z /new/mysql/dir

si vous voyez une différence, c'est probablement votre problème. Pour modifier ceci :

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

le commutateur R est pour la récursion. Si vous avez seulement besoin de modifier un fichier, vous pouvez l'omettre. Si votre contexte est différent du mien (peut-être une distro différente), utilisez celui indiqué par la sortie du premier (il devrait être le 3ème champ du truc SELinux)

ls -Z /var/lib/mysql 

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

getenforce

si elle répond avec Enforcing vous avez SELinux en marche. Désactiver temporairement avec setenforce 0 et voir si MariaDB commence maintenant! Assez fréquent, surtout sur RHEL / CentOS / Fedora.

il y a plus à ce sujet plus bas, aussi bien que dans cet article officiel.

En général

il y a plus de choses dans un environnement UNIX qui pourraient empêcher file accès, que les droits d'accès de l'utilisateur.

• des modules de sécurité comme SELinux (voir ci-dessus) ou AppArmor (comme Dan l'a mentionné) pourraient le désactiver
• les listes de contrôle D'accès (ACL) peuvent être définies spécifiquement, pour les fichiers/répertoires requis
• N'importe lequel des dossiers parents pourrait être la propriété d'un autre utilisateur, et n'avoir aucun x (="accès dir") défini pour les autres

en Outre, il pourrait y avoir d'autres facteurs inattendus, comme ...

• mysql datadir étant défini à un endroit, où mysql n'a pas de permissions (voir /etc/my.cnf)
• Mysql pourrait (étrangement) fonctionner comme un utilisateur différent, ou le fichier pourrait simplement être la propriété de quelqu'un d'autre

juste pour mentionner une vue des choses sur le dessus de ma tête (n'hésitez pas à éditer/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é ...

restorecon -R /var/lib/mysql/

... ou tout simplement désactiver SELinux (mais pensez à celui-ci un peu avant de le faire), en éditant la configuration (typiquement en /etc/selinux/config) et le paramètre SELINUX=disabled comme suggéré dans l'article suivant.

• voici le officiel page d'aide de mariadb.com: Que faire si MariaDB ne démarre pas
• et ici quelque chose de redhat.com:MariaDB Change De Base De Données Emplacement

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

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

répertoire de Travail /var/lib/mysql

plus Tôt /var/lib/mysql a été possédé par un inconnu de l'utilisateur

Changé à mysql

mysql]# chown -R mysql:mysql *

mysql]# service mariadb start

Redirecting to /bin/systemctl start mariadb.service

Fonctionne comme un charme

Quand cette surgi pour moi, j'ai trouvé la réponse dans le /etc/mysql/my.cnf fichier de configuration. datadir la ligne ne pointait pas vers le /var/lib/mysql répertoire (où les bases de données). Une fois que j'ai mis ce chemin, le serveur a redémarré sans problème.

j'ai eu exactement le même problème sur ma boîte de CentOS. Après avoir déplacé le répertoire de données mysql, Je ne pouvais plus démarrer le service, même si j'avais copié les fichiers avec le même propriétaire et les mêmes permissions.

j'ai eu un problème avec le contexte de sécurité SELinux. Si vous lancez votre stock de CentOS il a de bonnes chances d'être activé et ne laissera pas faire ce que vous voulez avec MySQL. Pour résoudre ce problème :

comparez D'abord l'ancien dir et le nouveau dir en utilisant

ls -Z /var/lib/mysql 

et

ls -Z /new/mysql/dir

si vous voyez une différence, c'est probablement votre problème. Pour modifier ceci :

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

le commutateur R est pour la récursion. Si vous avez seulement besoin de modifier un fichier, vous pouvez l'omettre.

dans ma situation est le problème de Selinux. Et le

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'utilise donc le commandement!--2-->.

si vous avez ce problème sur un NAS de Synologie, vous pouvez le corriger en suivant les conseils de L'équipe de soutien de Synologie:

Cher Utilisateur,

ceci a été confirmé comme un problème connu et nous essaierons de corriger ce problème dans une version ultérieure de MariaDB. 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 (même en tant qu'admin)
• exécuter la commande "echo 1 > /var / services / mysql / VERSION"
• ouvrir MariaDB paquet de DSM va déclencher la mise à jour de
• tapez le mot de passe DB et cliquez sur Update pour corriger ce problème

Plus d'info: Forum De Synologie

si vous utilisez SEL Linux

Intall semanage

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

voir le contexte de sécurité mysqld

après l'installation yum install policycoreutils-python vous pouvez simplement regarder le contexte de sécurité différent de 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

ici vous voyez tout le 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 - journal les fichiers
4. mysqld_exec_t - exécution de fichiers

donc si vous avez le mauvais contexte de sécurité sur vos fichiers vous obtenez une permission refusée (erreur 13)

Solution

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

mais vérifiez aussi les permissions" normales". J'ai eu ce problème avec centos. Vous devez vous systemctl restart mysql pour les changements.

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.