The server cannot delete the database directory when processing DROP DATABASE, so MySQL raises error 1009 (ER_DB_DROP_DELETE).
MySQL Error 1009 ER_DB_DROP_DELETE signals that DROP DATABASE failed because the server could not delete the database directory, often due to file-system permissions or open locks. Close active sessions, correct directory ownership, then rerun DROP DATABASE to resolve the issue.
Error dropping database (can't delete '%s', errno: %d)
MySQL throws error code 1009 (condition ER_DB_DROP_DELETE, SQLSTATE HY000) when a DROP DATABASE statement cannot remove the database directory on disk. The accompanying errno value indicates the specific operating-system failure, such as permission denied (13) or directory not empty (39).
The error halts the drop operation, leaving the schema and its files partially intact.
Fixing it quickly prevents orphaned objects, frees disk space, and allows you to recreate the database with the same name without conflicts.
The message appears immediately after running DROP DATABASE db_name; or mysqladmin drop db_name when MySQL lacks OS-level rights, the directory contains non-database files, or tables remain open.
It can also surface in replication, CI pipelines, or during automated teardown scripts.
Unresolved, the leftover directory can block backups, schema migrations, and container rebuilds. Continuous-integration jobs that expect a clean environment will fail repeatedly until the underlying OS problem is fixed.
Typical triggers include incorrect directory ownership, residual files created by other tools, active connections keeping .ibd or .frm files open, or disk problems.
The errno value inside the message pinpoints the root cause.
Always start by reading the errno. Close open sessions with FLUSH TABLES WITH READ LOCK;, fix directory permissions with chown -R mysql:mysql /var/lib/mysql/db_name, or manually remove stray files after stopping MySQL.
Re-run DROP DATABASE once the obstacle is cleared.
Grant the MySQL user full ownership of files in the data directory, use consistent lower_case_table_names settings, and ensure applications release connections before schema-level changes. Automate checks in Galaxy or your CI pipeline to detect lingering locks.
Similar OS-related DDL failures include Error 1010 (ER_DB_DROP_RMDIR) and Error 1025 (ER_DROP_CANNOT_SWITCH). They share root causes but differ in object type (schema vs table).
Fix them with the same permission and lock-clearing techniques.
.
The MySQL process lacks write or delete permission on the database directory.
This often happens after manual file copies or incorrect deployment scripts.
Non-table files or hidden OS files remain in the directory, so the operating system refuses to remove it.
Active sessions, long-running queries, or backup tools hold locks on .ibd or .frm files, preventing deletion.
Corrupted file systems, read-only mounts, or full disks cause the delete syscall to fail even with correct permissions.
.
No. MySQL requires the directory to be deletable. You must resolve the underlying OS issue before dropping.
Errno 13 is a Linux code for "Permission denied". Fix by giving the MySQL user write and delete rights on the directory.
Yes, but stop MySQL first, back up, delete the directory, then run DROP DATABASE IF EXISTS to clean metadata.
Galaxy flags the exact errno, lets you share the failing DROP statement, and tracks fixes in version history so teams avoid repeating the mistake.
.avif)
.avif){kind=logo}
