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

Je suis sous Mysql sur ubuntu 9.10,
le processus de Mysql exécute en tant que root, je suis en utilisant le compte root lors de la connexion à Mysql à qui j'ai donné tous les privilèges, je suis en utilisant ma propre db(pas mysql), je peux créer une table, mais lorsque j'essaie de créer une table Temporaire, j'obtiens cette erreur:

ERREUR 1005 (HY000): ne Peut pas créer la table 'tmp' (errno: 13)

Pour cette requête:

CRÉER une TABLE TEMPORAIRE tmp (id int);

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

Une idée?
Merci,
Coby

source d'informationauteur koby

  1. 27

    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é possédé par le mal de l'utilisateur.
    Un simple chown -R mysql:mysql /var/lib/mysql/database_name a fait le tour!

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

    Acclamations

  2. 4

    Bien...
    dans /etc/mysql/my.cnf, il y a la "tmp" dossier de l'usage qui est /tmp (de la racine) en tant que par défaut.. et n'ont pas de privilèges mysql.
    chmod 0777 /tmp fera l'affaire

  3. 2

    J'ai eu l'erreur ci-dessus avec les bonnes permissions sur /tmp, dans le bon contexte et de suffisamment d'espace disque sur Fedora 16.

    Après une journée de ripper mes cheveux, j'ai suivi le problème à un paramètre dans systemd configuration pour le service MySQL.

    Dans /etc/systemd/system/multi-user.target.wants/mysqld.service vérifier si il y a un paramètre PrivateTmp=true. Ce changement, les forces de MySQL à utiliser un /tmp/systemd-noms-XXXXX sous-répertoire au lieu de mettre directement les fichiers dans /tmp. Apparemment, MySQL n'aime pas ça et échouer avec une erreur permission denied (13) pour toute requête qui a exigé la création d'un fichier temp.

    Vous pouvez remplacer 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 de recharger la configuration en cours d'exécution: systemctl daemon-reload et redémarrer MySQL.

  4. 1

    ne vous définissez l'attribut MaxNoOfOrderedIndexes dans votre config.ini?
    C'est la valeur par défaut est de 128,donc si vous avez beaucoup de tables pour créer,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

  5. 1

    J'ai eu le même problème aujourd'hui sur mon Amazon Red Hat instance. J'ai été en mesure d'effectuer ni mysql decribe (à partir de mysql shell) ni exécuter la commande mysqldump. Pour résoudre cela, 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.journal j'ai encore vu:

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

    Il s'est avéré que c'était SELinux qui ne permettaient pas le démon MySQL à écrire dans /tmp. Donc, ce que j'ai fait était de:

    # getenforce 
Enforcing

    Pour vérifier si SELinux est en cours d'exécution dans l'application mode (vous pouvez lire plus sur ce ici). Le rapide et rapide solution pour cela est de 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 endurcis de production, vous devez être très prudent lorsque vous passez d'application facultative. veuillez également noter que ce paramètre sera réinitialisé après le redémarrage de l'ordinateur.

  6. 0

    J'ai eu ces (errno: 13) erreurs et seulement pensé après regarde dans /var/log/syslog, donc mon conseil est le suivant:

    tail -f /var/log/syslog

    Voir si cela n'a rien à voir avec les fichiers de base de données après que vous essayez d'accéder à la base de données, dans mon cas, c'était

    apparmor=[DENIED]

    Ce qui signifie que vous devez traiter avec apparmor, mais dans votre cas, il pourrait être quelque chose d'autre.

  7. 0

    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.