MySQL cannot release a file lock on a table because the operating system reports the resource is still busy.
MySQL Error 11: EE_CANTUNLOCK happens when the server cannot release a file lock on a table. Close competing processes, ensure local storage, and restart MySQL to clear lingering locks.
Can't unlock file (OS errno %d - %s)
MySQL raises "Can't unlock file (OS errno 11 - Resource temporarily unavailable)" when it cannot release a file lock on a table’s .frm, .ibd, or .MYD/.MYI file. The operating system signals that another process still holds the lock, blocking MySQL from finishing the current statement.
This global error can surface during INSERT, UPDATE, SELECT ... FOR UPDATE, ALTER TABLE, or replication events.
It is common on shared or networked storage, under heavy concurrency, or when antivirus or backup software touches MySQL data files. Resolving the conflict quickly restores database availability and protects data integrity.
Lingering file locks from crashed clients or killed threads keep the table busy, so MySQL cannot unlock it.
External processes such as rsync, antivirus scans, or backup agents may open the file with exclusive or shared locks, preventing MySQL from releasing its own.
Network file systems (NFS, SMB, EFS) introduce higher lock-manager latency. If lock requests time out, MySQL retries and eventually emits EE_CANTUNLOCK.
High-concurrency workloads on InnoDB can also exhaust the lock table, causing failed unlock attempts.
First, identify the operating-system process that owns the blocking lock with lsof +D /var/lib/mysql or fuser -v. If it is non-MySQL, stop or pause it. If it is a defunct MySQL thread, restart the server to clear the handle.
Move data off network storage to local disks when possible. Increase innodb_open_files and verify open_files_limit is well above the total number of tables.
Use short transactions to release locks promptly and avoid long-running ALTER statements at peak load.
Backup program holds lock: Pause the backup, flush tables, and retry the query.
NFS share latency: Mount with nolock when safe or migrate to local SSD storage.
Un-killed session in processlist: Execute KILL CONNECTION <id> then run FLUSH TABLES.
Configure backups to use MySQL-native mechanisms (mysqldump, mysqlpump, Percona XtraBackup) instead of file-level copies.
Keep innodb_flush_method set to O_DIRECT on Linux to reduce kernel lock contention.
Monitor performance_schema.file_summary_by_instance for long waits. In Galaxy, enable query history and lock-wait visualizations to spot problematic code paths early.
MySQL Error 9: EE_BADF – bad file descriptor. Usually indicates closed file handle; restart threads.
MySQL Error 12: EE_OUTOFMEMORY – memory allocation failed. Tune innodb_buffer_pool_size.
MySQL Error 13: EE_CANTCREATE – cannot create file. Check permissions and disk space.
.
A previous mysqld instance crashed while holding a table lock.
The OS keeps the lock until reboot or manual release.
Backup, antivirus, rsync, or manual copy commands open the data file with a lock, blocking MySQL's unlock call.
Lock requests to NFS/SMB file servers time out or are delayed, so MySQL cannot complete UNLOCK before the internal timer expires.
If open_files_limit is too low, MySQL may fail to reopen a file to unlock it, returning EE_CANTUNLOCK.
.
No data corruption is recorded. The error aborts the current statement, but storage engines keep consistency.
Only if external processes cannot be stopped or the lock belongs to a zombie MySQL thread. Most cases clear with FLUSH TABLES.
Ignoring will cause replication lag or stops. Fix on the source and restart the replica IO thread.
Galaxy surfaces lock waits in real time, lets teams kill blocking sessions from the editor, and shares root-cause notes in Collections.
.avif)
.avif){kind=logo}
