Mysql ERROR 1005 (HY000): No se puede crear la tabla 'tmp' (errno: 13)

Question

Estoy ejecutando Mysql en ubuntu 9.10, el proceso de Mysql se está ejecutando como root, estoy usando la cuenta de root al iniciar sesión a Mysql, que le di todos los privilegios, estoy usando mi propio db (no mysql), puedo crear una tabla, pero cuando intento crear una tabla temporal obtengo este error:

ERROR 1005 (HY000): no se puede crear la tabla 'tmp' (Error: 13)

Para esta consulta:

cREAR tABLA TEMPORAL tmp (id int);

Tengo un montón de espacio en mi disco duro, todos los permisos están concedidos (también var/lib/mysql tienen permisos de mysql).

¿Alguna idea? Gracias , Koby

Answer 1

Bueno ... en /etc/mysql/my.cnf existe la carpeta "tmp" para su uso, que es/tmp (de raíz) como por defecto .. y no tienen privilegios de MySQL. chmod 0777/tmp hará el truco

Answer 2

Tuve el mismo problema hace un par de semanas. La carpeta de la base de datos en el sistema de archivos era propiedad del usuario equivocado. ¡Un simple chown -R mysql:mysql /var/lib/mysql/database_name hizo el truco!

Todo está explicado aquí: http://www.dinosources.eu/2010/10/mysql-cant-create-table (que es italiano, pero es bastante clara)

Saludos

Answer 3

hay que ajustar las MaxNoOfOrderedIndexes atributos en su config.ini? Su valor predeterminado es 128, por lo tanto, si tiene muchas tablas para crear, las últimas no se pueden crear. véase: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-maxnooforderedindexes

Answer 4

que tenía el error anterior con permisos correctos en/tmp, el contexto correcto y suficiente espacio en disco en Fedora 16.

Después de un día de rasgar mi pelo, me rastreado el problema hasta una configuración en configuración de sistema para el servicio MySQL.

En /etc/systemd/system/multi-user.target.wants/mysqld.service compruebe si hay una configuración PrivateTmp=true. Este cambio obliga a MySQL a usar un subdirectorio/tmp/systemd-namespace-XXXXX en lugar de poner archivos directamente en/tmp. Aparentemente a MySQL no le gusta eso y falla con un error de permiso denegado (13) para cualquier consulta que requiera la creación de un archivo temporal.

Puede anular esta configuración de la siguiente manera:

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

vuelva a cargar configuración ejecutando: systemctl daemon-reload y reiniciar MySQL.

Answer 5

Tuve el mismo problema hoy en mi instancia de Amazon Red Hat. Pude realizar ni mysql decribe (desde mysql shell) ni ejecutar mysqldump. Para resolver esto probé la solución más obvia:

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

Pero esto no ayudó. En/var/log/mysqld.conecto todavía veía:

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. 

se supo que era SELinux que no permitía MySQL demonio va a escribir en/tmp. Por lo tanto, lo que hice fue:

# getenforce 
Enforcing 

Para verificar si SELinux está ejecutado en modo obligatorio (se puede leer más acerca de este here). La solución rápida y rápida para esto fue cambiar al modo permisivo SELinux:

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

Lo anterior resolvió mi problema.

Tenga en cuenta que, si está trabajando en la producción reforzada, debe tener mucho cuidado cuando cambie de aplicar a permisivo. tenga en cuenta que esta configuración específica se restablecerá después del reinicio.

Answer 6

que estaba teniendo estos (errno: 13) errores y sólo a ellos descubrí después de mirar en/var/log/syslog, así que mi consejo es el siguiente:

tail -f /var/log/syslog 

A ver si eso tiene algo que ver con archivos de base de datos después de intentar acceder a la base de datos, en mi caso fue

apparmor=[DENIED] 

que significa que necesita para hacer frente a apparmor, pero en tu caso podría ser otra cosa.

Answer 7

con mi caso:

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

resuelto mi problema.