mysql - solucion - error dropping database(can''t rmdir errno 41)

MySQL: error al eliminar la base de datos(errno 13; errno 17; errno 39)

Question

Fallé al eliminar una base de datos:

mysql> drop database mydb; ERROR 1010 (HY000): Error dropping database (can''t rmdir ''./mydb'', errno: 39)

El directorio db / mydb existe en el árbol mysql pero no tiene tabla:

# ls -l db/mydb -rw-rw---- mysql mysql HIS_STAT.MYD -rw-rw---- mysql mysql HIS_STAT.MYI

¿Que debería hacer?

Answer 1

Errno 13

MySQL no tiene permiso de escritura en el directorio principal en el que reside la carpeta mydb .

Compruébalo 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 mezclas y combinas los paquetes 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 otra parte (por ejemplo: /var/lib/mysql5/data/** diferencia de /var/lib/mysql/** ). Entonces, lo que ves es que el directorio tiene los permisos y la propiedad correctos y, sin embargo, todavía le da Errno 13 porque apparmor / selinux no permitirá el acceso a él.

Para verificar, verifique las violaciones de seguridad en el registro del sistema, inspeccione manualmente la configuración de apparmor / selinux y / o suplante al usuario mysql e intente ir al directorio var básico, luego cd incrementalmente hasta que esté en el directorio de destino y ejecute 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.

Errno 39

Este código significa "directorio no vacío". El directorio contiene algunos archivos ocultos de los que MySQL no sabe nada. Para archivos no ocultos, vea Errno 17. La solución es la misma.

Errno 17

Este código significa "archivo existe". El directorio contiene algunos archivos MySQL que MySQL no tiene la intención de eliminar. Dichos archivos podrían haber sido creados por un SELECT ... INTO OUTFILE "filename"; comando donde el filename no tiene 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 , por ejemplo /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)

Mueva el (los) archivo (s) fuera (o elimine 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: mira abajo ...

ACTUALIZACIÓN: Error 17 como indicador de explotación

Esto sucedió en un sistema Linux con Wordpress instalado. Desafortunadamente, el cliente tenía limitaciones de tiempo y no pude ni crear una imagen del disco ni hacer una verdadera ronda forense: volví a instalar toda la máquina y Wordpress se actualizó en el proceso, por lo que solo puedo decir que estoy casi seguro de que lo hicieron a través de este plugin .

Síntomas : el directorio de datos mysql contenía tres archivos con extensión PHP. ¿¡¿Esperar lo?!? - y dentro de los archivos había una gran cantidad de código base64 que se pasó a gzuncompress , gzuncompress y [eval()][2] . Aha . Por supuesto, estos fueron solo los primeros intentos, los fracasados. El sitio ha sido bien y verdaderamente pwn3d.

Entonces, si encuentra un archivo en su directorio de datos mysql que está causando un Error 17, verifíquelo con file utilidad de file o escanearlo con un antivirus. O inspeccionar visualmente su contenido. No suponga que está ahí por algún error inocuo.

La víctima en este caso (hizo que un amigo "hiciera el mantenimiento") nunca hubiera adivinado que había sido pirateado hasta que una secuencia de comandos de mantenimiento / actualización / lo hiciera ejecutar una DROP DATABASE ( no me preguntes por qué, ni siquiera estoy seguro Quiero saber ) y obtuve 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.

Sin embargo, otro error 17

Si rsync o copia entre dos instalaciones de MySQL de la misma versión pero diferentes plataformas o sistemas de archivos como Linux o Windows (que se desaconseja, y es arriesgado, pero muchos lo hacen) y específicamente con diferentes configuraciones de sensibilidad de mayúsculas y minúsculas , puede accidentalmente terminar con dos versiones del mismo archivo (ya sea datos, índice o metadatos); dicen 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 soltar la base de datos, que también ocurre en muchos mysqldump ... | ... mysql mysqldump ... | ... mysql esquemas de copia de seguridad mysqldump ... | ... mysql , DROP fallará porque ese archivo adicional (o esos archivos adicionales) existe. Si esto ocurre, debería 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.

Encontrar el dir de datos

En general, puede encontrar el directorio de datos inspeccionando el archivo /etc/my.cnf ( /etc/my.cnf , /etc/sysconfig/my.cnf , /etc/mysql/my.cnf en Linux; my.ini en MySQL directorio de archivos de programa en Windows), bajo el encabezado [mysqld] , como datadir .

Alternativamente, puedes preguntarlo a MySQL:

mysql> SHOW VARIABLES WHERE Variable_name LIKE ''%datadir%'';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+
1 row in set (0.00 sec)

Answer 2

En cuanto a ERRORCODE 39 , simplemente puede eliminar los archivos de la tabla física en el disco. la ubicación depende de la distribución y configuración de su sistema operativo. En Debian está típicamente en / var / lib / mysql / database_name / Así que haz un:

rm -f /var/lib/mysql/<database_name>/

Y luego suelte la base de datos de su herramienta preferida o use el comando:

DROP DATABASE <database_name>

Answer 3

En mi caso, se debió al parámetro ''low_case_table_names''.

El error número 39 arrojado cuando traté de soltar las bases de datos que consiste en nombres de tablas en mayúsculas con el parámetro lower_case_table_names está habilitado.

Esto se soluciona invirtiendo los cambios de parámetros en minúsculas al estado anterior.

Answer 4

Simplemente vaya a / opt / lampp / var / mysql

Allí puede encontrar su nombre de la base de datos. Abre esa carpeta. Eliminar si hay archivos en ella

Ahora ve a phpmyadmin y abandona esa base de datos

Answer 5

en Linux, simplemente vaya a "/ var / lib / mysql", haga clic derecho y (abrir como administrador), busque la carpeta correspondiente al nombre de su base de datos dentro de la carpeta mysql y elimínela. Eso es. La base de datos se descarta.