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

StackOverflow https://stackoverflow.com/questions/2476272

Question

Je suis en Mysql sur ubuntu 9.10, le processus de Mysql est en cours d'exécution en tant que root, j'utilise le compte root lors de la connexion à Mysql, que j'ai donné tous les privilèges, j'utilise ma propre db (MySQL), je peux créer une table, mais lorsque je tente de créer table temporaire je reçois cette erreur:

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

Pour cette requête:

CREATE TEMPORARY TABLE tmp (id int);

J'ai beaucoup d'espace dans mon disque dur, toutes les autorisations sont accordées (aussi var / lib / mysql mysql permissions Have).

Une idée? Merci, Koby

Était-ce utile?

La solution 2

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 pas avoir des privilèges de MySQL. chmod 0777 / tmp fera l'affaire

Autres conseils

J'ai eu le même problème il y a quelques semaines. Le dossier de base de données sur le système de fichiers a été la propriété de l'utilisateur incorrect. 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

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 origine du problème: un paramètre dans la configuration systemd pour le service MySQL.

vérification de /etc/systemd/system/multi-user.target.wants/mysqld.service pour s'il y a un PrivateTmp=true de réglage. Cette modification force MySQL à utiliser / tmp / systemd-espace-XXXXX sous-répertoire au lieu de mettre les fichiers directement dans / tmp. Apparemment, MySQL n'aime pas et échoue avec une erreur de permission refusée (13) pour toute requête qui a nécessité 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

Ensuite, recharger la configuration en cours d'exécution: systemctl daemon-reload et redémarrez MySQL

.

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

J'ai eu le même problème aujourd'hui sur mon exemple Red Hat Amazon. J'ai pu effectuer ni mysql decribe (shell de mysql), ni exécuter mysqldump. Pour résoudre ce que 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.log je 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: 

# getenforce 
Enforcing

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

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

Ce qui précède a résolu mon problème.

S'il vous plaît noter que, si vous travaillez sur la production durcie, vous devriez être très prudent lorsque vous passez d'application à permissive. S'il vous plaît noter également que ce paramètre spécifique sera remis à zéro après le redémarrage.

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.

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.

Si elle est installée PhpMyAdmin avec XAMPP sur Linux, l'utilisateur peut être défini dans ce chemin:

sudo chown -R mysql:mysql /opt/lampp/var/mysql/my_database

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top