I No se pudo quitar una base de datos:MySQL: Error de base de datos de caer (Error 13; errno 17; errno 39)
mysql> drop database mydb; ERROR 1010 (HY000): Error dropping database (can't rmdir './mydb', errno: 39)
directorio db/existe mibd en el árbol de MySQL pero no tiene ninguna tabla:
# ls -l db/mydb -rw-rw---- mysql mysql HIS_STAT.MYD -rw-rw---- mysql mysql HIS_STAT.MYI
¿Qué debo hacer?
MySQL no tiene permiso de escritura en el directorio principal en la que reside la carpeta mydb.
Compruebe con
ls -la /path/to/data/dir/ # see below on how to discover data dir
ls -la /path/to/data/dir/mydb
En Linux, esto también puede suceder si usted mezclar y combinar los paquetes de MySQL y AppArmor/SELinux. Lo que sucede es que AppArmor espera que mysqld tenga sus datos en /path/to/data/dir, y permite R/W completo allí, pero MySQLd es de una distribución o construcción diferente, y en realidad almacena sus datos en otro lugar (p. Ej .: /var/lib/mysql5/data/** en comparación con /var/lib/mysql/**) . Entonces, lo que ves es que el directorio tiene permisos correctos y propiedad y aún así le da a Errno 13 porque apparmor/selinux no permitirá el acceso a él.
Para verificar, verifique el registro del sistema en busca de violaciones de seguridad, inspeccione manualmente la configuración de apparmor/selinux y suplante el usuario mysql e intente ir al directorio var básico, luego cd incrementalmente hasta que esté en el directorio de destino, y ejecuta algo como touch aardvark && rm aardvark. Si los permisos y la propiedad coinciden, y sin embargo, lo anterior produce un error de acceso, es probable que se trate de un problema de seguridad.
Este código significa "directorio no está vacío". El directorio contiene algunos archivos ocultos de los cuales MySQL no sabe nada. Para archivos no ocultos, vea Errno 17. La solución es la misma.
Este código significa que "existe el archivo". El directorio contiene algunos archivos MySQL que MySQL no tiene la intención de eliminar. Dichos archivos podrían haberse creado mediante un comando SELECT ... INTO OUTFILE "filename"; donde filename no tenía ruta. En este caso, el proceso MySQL los crea en su directorio de trabajo actual, que (probado en MySQL 5.6 en OpenSuSE 12.3) es el directorio de datos de la base de datos, p. /var/lib/mysql/data/nameofdatabase.
Reproducibilidad:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1676
Server version: 5.6.12-log openSUSE package
[ snip ]
mysql> CREATE DATABASE pippo;
Query OK, 1 row affected (0.00 sec)
mysql> USE pippo;
Database changed
mysql> SELECT version() INTO OUTFILE 'test';
Query OK, 1 row affected (0.00 sec)
mysql> DROP DATABASE pippo;
ERROR 1010 (HY000): Error dropping database (can't rmdir './pippo/', errno: 17)
-- now from another console I delete the "test" file, without closing this connection
-- and just retry. Now it works.
mysql> DROP DATABASE pippo;
Query OK, 0 rows affected (0.00 sec)
mover el archivo (s) exterior (o eliminar si no es necesario) y vuelva a intentarlo. Además, determine por qué se crearon en primer lugar, podría señalar un error en alguna aplicación. O peor: ver a continuación ...
Esto sucedió en un sistema Linux con Wordpress instalado.Lamentablemente, el cliente tenía limitaciones de tiempo y no podía ni crear una imagen del disco ni hacer una verdadera ronda forense: reinstalé toda la máquina y Wordpress se actualizó en el proceso, por lo que solo puedo decir que soy casi seguro que lo hicieron a través de this plugin.
Síntomas: el directorio de datos mysql contenía tres archivos con la extensión PHP. Espera, ¿qué?!? - y dentro de los archivos había una gran cantidad de código base64 que se pasó a base64_decode, gzuncompress y [eval()][2]. Aha. Por supuesto, estos fueron solo los primeros intentos, los fracasados. El sitio ha sido bien y verdaderamente pwn3d.
Así que si encuentra un archivo en su directorio de datos mysql que está causando un error 17, compruébelo con file utilidad o escanearlo con un antivirus. O inspeccionar visualmente su contenido. No suponga que está allí por algún error inocuo.
La víctima en este caso (que tenía algún amigo "hacer el mantenimiento") nunca habría adivinado que había sido hackeado hasta que un mantenimiento/actualización/lo que sea Script ejecutado un DROP DATABASE (no me pregunte por qué - I No estoy seguro, incluso quiero saber) y me dieron un error. Desde la carga de la CPU y los mensajes syslog, estoy bastante seguro de que el host se ha convertido en una granja de correo no deseado.
Si rsync o copiar entre dos instalaciones de MySQL de la misma versión pero diferentes sistemas de plataforma o de archivos como Linux o Windows (que no es recomendable, y arriesgado, pero muchos lo hacen no obstante), y específicamente con diferentes configuraciones case sensitivity, puede terminar accidentalmente con dos versiones del mismo archivo (ya sea datos, índice o metadatos); diga Customers.myi y Customer.MYI. MySQL usa uno de ellos y no sabe nada del otro (que podría estar desactualizado y conducir a una sincronización desastrosa). Al eliminar la base de datos, que también ocurre en muchos esquemas de copia de seguridad mysqldump ... | ... mysql, el DROP fallará porque existe ese archivo adicional (o esos archivos adicionales). Si esto sucede, debe poder reconocer los archivos obsoletos que necesitan eliminación manual de la hora del archivo, o del hecho de que su esquema de caso es diferente de la mayoría de las otras tablas.
En general, se puede encontrar el directorio de datos mediante la inspección del archivo my.cnf (/etc/my.cnf, /etc/sysconfig/my.cnf, /etc/mysql/my.cnf en Linux; my.ini en el directorio de archivos de programa de MySQL en Windows), bajo la [mysqld] encabezado, como datadir.
Alternativamente puede preguntar a sí MySQL:
mysql> SHOW VARIABLES WHERE Variable_name LIKE '%datadir%';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| datadir | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)
Gracias @ xk0der por el heads-up (pero creo que debería haber sido en realidad un * comentario *). Sugerencia sobre 'my.cnf' agregado a la respuesta. Lo de errno 13 puede ser útil para las personas que vienen a solucionar problemas, así que decidí quedármelo. – LSerni
En mi caso, estaba intentando tomar un volcado de una tabla usando OUTFILE y ese archivo se guardó en el directorio de datos bajo el nombre de la base de datos. Lo resolvió borrando ese archivo. – Taranjeet
En mi caso fue debido al parámetro '' lower_case_table_names.
Aparece el error número 39 cuando traté de soltar las bases de datos que constan de nombres de tablas en mayúsculas con el parámetro lower_case_table_names habilitado.
Esto se soluciona al revertir los cambios de parámetros de minúsculas al estado anterior.
Es cierto. Podría ser debido a esa configuración. BUt, revertir esa configuración no es la solución correcta, sino un compromiso en mi humilde opinión. –
Eso resolvió mi problema. Puede revertirlo, borrar sus bases de datos y revertirlo ... – c4k
sí, esa fue la razón conmigo –
sólo tiene que ir a/opt/lampp/var/mysql
No puede encontrar su nombre datavase. Abra esa carpeta. Retire si todos los archivos en el mismo
Ahora vienen a phpmyadmin y soltar esa base de datos
suena como un problema de permisos. ¿Puedes publicar un resultado 'ls -l' completo? –
@Chris Henry: He actualizado la pregunta con el resultado de # ls -l mydb –