Mysql ERROR 1005 (HY000): Impossible de créer la table 'tmp' (errno: 13)

Question

Je cours Mysql sur Ubuntu 9.10, le processus de Mysql est en cours d'exécution en tant que root, j'utilise root compte lors de la journalisation à Mysql, que j'ai donné tous les privilèges, j'utilise mon propre DB (pas mysql), je peux créer une table, mais quand j'essaye de créer la table temporaire j'obtiens cette erreur:

ERROR 1005 (HY000): Impossible de créer la table 'tmp' (errno: 13)

Pour cette requête:

CREATE TABLE tmp TEMPORAIRE (id int); J'ai beaucoup d'espace dans mon disque dur, toutes les autorisations sont accordées (aussi var/lib/mysql ont des autorisations mysql).

Une idée? Merci, Koby

Answer 1

... Eh bien dans /etc/mysql/my.cnf il y a le dossier « tmp » pour ce qui est/tmp (de la racine) par défaut .. et ne disposent pas de privilèges MySQL. chmod 0777/tmp fera l'affaire

Answer 2

J'ai eu le même problème il y a quelques semaines. Le dossier de la base de données sur le système de fichiers appartenait au mauvais utilisateur. Un simple chown -R mysql:mysql /var/lib/mysql/database_name a fait l'affaire!

Tout est expliqué ici: http://www.dinosources.eu/2010/10/mysql-cant-create-table (il est italien, mais il est assez clair)

Vive

Answer 3

vous définissez les MaxNoOfOrderedIndexes d'attributs dans votre config.ini? Sa valeur par défaut est 128, donc si vous avez beaucoup de tables à créer, le dernier d'entre eux ne peut pas être créé. voir: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-maxnooforderedindexes

Answer 4

j'ai eu l'erreur ci-dessus avec des autorisations correctes sur/tmp, contexte correct et suffisamment d'espace disque sur Fedora 16.

Après une journée de déchirer mes cheveux, je suivis le problème à un paramètre dans la configuration systemd pour le service MySQL.

En /etc/systemd/system/multi-user.target.wants/mysqld.service chèque s'il y a un paramètre PrivateTmp=true. Cette modification oblige MySQL à utiliser un sous-répertoire/tmp/systemd-namespace-XXXXX au lieu de placer les fichiers directement dans/tmp. Apparemment, MySQL n'aime pas cela et échoue avec une erreur d'autorisation refusée (13) pour toute requête nécessitant la création d'un fichier temporaire.

Vous pouvez modifier ce paramètre comme suit:

cat >> /etc/systemd/system/mysqld.service << END_CONFIG 
.include /lib/systemd/system/mysqld.service 
[Service] 
PrivateTmp=false 
END_CONFIG 

Puis recharger la configuration en exécutant: systemctl daemon-reload et redémarrez MySQL.

Answer 5

J'ai eu la même question aujourd'hui sur mon exemple Red Hat Amazon. Je n'ai pu exécuter ni mysql decribe (à partir de mysql shell) ni exécuter mysqldump. Pour résoudre ce problème, j'ai essayé la solution la plus évidente:

# chown root:root /tmp -v 
# chmod 1777 /tmp -v 
# /etc/init.d/mysqld restart 

Mais cela n'a pas aidé. Dans le/var/log/mysqld.Je connecte encore vu:

141022 10:23:35 InnoDB: Error: unable to create temporary file; errno: 13 
141022 10:23:35 [ERROR] Plugin 'InnoDB' init function returned error. 
141022 10:23:35 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 

Il est sorti qu'il était SELinux qui ne permettait pas le démon MySQL pour écrire à/tmp. Par conséquent, ce que je faisais était de:

# getenforce 
Enforcing 

Pour vérifier si SELinux est en cours d'exécution en mode application (vous pouvez en savoir plus sur ce here). La solution rapide et rapide pour cela devait passer à SELinux en mode permissif:

# setenforce 0 
# getenforce 
Permissive 
# /etc/init.d/mysqld restart 

ci-dessus a résolu mon problème.

Veuillez noter que, si vous travaillez sur une production durcie, vous devez être très prudent lorsque vous passez de l'application à la permissivité. veuillez également noter que ce paramètre spécifique sera réinitialisé après le redémarrage.

Answer 6

Je faisais ces (errno: 13) erreurs et ne les figuré dehors après avoir regardé dans/var/log/syslog, donc mon conseil est le suivant:

tail -f /var/log/syslog 

Voyez si cela n'a rien à voir avec les fichiers de base de données une fois que vous essayez d'accéder à la base de données, dans mon cas, il était

apparmor=[DENIED] 

ce qui signifie que vous devez traiter AppArmor, mais dans votre cas, il pourrait être autre chose.

Answer 7

avec mon cas:

# semanage fcontext -a -t mysqld_db_t "/datadir(/.*)?" 
    # restorecon -Rv /datadir 
    #chcon -R -t mysqld_db_t /datadir 

résolu mon problème.