Errno 13

MySQL no tiene permiso de escritura en el directorio padre 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 mezcla y combina 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 compilación diferente, y en realidad almacena sus datos en otro lugar (por ejemplo: /var/lib/mysql5/data/** en lugar de /var/lib/mysql/**). Así que lo que ves es que el directorio tiene permisos correctos y propiedad y aún así da Errno 13 porque apparmor/selinux no permitirá el acceso a él.

Para verificar, revise el registro del sistema en busca de violaciones de seguridad, inspeccione manualmente la configuración de apparmor/selinux, y/o suplante al usuario de mysql e intente ir al directorio var base, luego cd gradualmente 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, lo más probable es que sea un problema de marco 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 los archivos no ocultos, ver Errno 17. La solución es la misma.

Errno 17

Este código significa "el archivo existe". El directorio contiene algunos archivos MySQL que MySQL no se siente sobre la eliminación. Estos archivos podrían haber sido creados por un comando SELECT ... INTO OUTFILE "filename"; donde filename no tenía camino. 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 elimínelo si no es necesario) y vuelva a intentarlo. También, determinar por qué se crearon en primer lugar - podría apuntar a un error en alguna aplicación. O peor: ver abajo...

ACTUALIZACIÓN: Error 17 as exploit flag

Esto sucedió en un sistema Linux con Wordpress instalado. Desafortunadamente, el cliente estaba bajo restricciones de tiempo y no podía ni imaginar el disco ni hacer una ronda forense real: Reinstalé toda la máquina y Wordpress se actualizó en el proceso, así que solo puedo decir que estoy casi seguro de que lo hicieron a través de este plugin.

Symptoms : el directorio de datos mysql contenía tres archivos con 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 fallidos. El sitio había 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 la utilidad file o escanéelo con un antivirus. O inspeccione visualmente su contenido. No asumas que está ahí para algunos inocuos error.

La víctima en este caso (tenía algún amigo "hacer el mantenimiento") nunca habría adivinado que había sido hackeado hasta que un script de mantenimiento/actualización/lo que sea ejecutó un DROP DATABASE (no me pregunte por qué-No estoy seguro de que incluso quiero saber ) y obtuvo un error. Por la carga de la CPU y los mensajes de syslog, estoy bastante seguro de que el host se había convertido en una granja de spam.

Otro error 17

Si rsync o copia entre dos instalaciones MySQL de la misma versión pero diferentes plataformas o sistemas de archivos como Linux o Windows (lo cual es desaconsejable y arriesgado, pero muchos lo hacen de todos modos), y específicamente con diferentes configuraciones de sensibilidad a mayúsculas y minúsculas, puede terminar accidentalmente con dos versiones del mismo archivo (ya sea datos, índice o metadatos); digamos Customers.myi y Customer.MYI. MySQL usa uno de ellos y no sabe nada sobre el otro (lo que podría estar desactualizado y llevar a una sincronización desastrosa). Al soltar la base de datos, que también sucede en muchos esquemas de copia de seguridad mysqldump ... | ... mysql, el DROP fallará porque ese archivo adicional (o esos archivos adicionales) existe. Si esto sucede, debería ser capaz de reconocer los archivos obsoletos que necesitan eliminación manual del tiempo de archivo, o del hecho de que su esquema de caso es diferente de la mayoría de las otras tablas.

Encontrando los datos-dir

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

Alternativamente puedes pedírselo a MySQL:

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