SQLITE_IOERR_LOCKERRORTier 2 — Caution⚠️ MEDIUM confidenceI/O error obtaining file lock
🔴 Production Risk Error
High — transaction cannot proceed; use local storage.
What this means
SQLITE_IOERR_LOCK (3850) is returned when the OS reports an error while SQLite is trying to acquire a file lock — distinct from SQLITE_BUSY, which indicates the lock is held by another process.
Why it happens
- 1Filesystem does not support POSIX advisory locks (some network filesystems).
- 2OS error (EIO, ENOMEM) during fcntl() lock call.
- 3Docker or container environment with non-standard file locking.
How to reproduce
Lock acquisition during BEGIN EXCLUSIVE or BEGIN IMMEDIATE.
# On NFS or some Docker volumes, fcntl() may return EIO
# → SQLITE_IOERR_LOCK instead of SQLITE_BUSYFix 1
Why this works
Use a local filesystem for SQLite databases.
Fix 2
Why this works
Use WAL mode which uses shared-memory instead of file locks for readers.
Fix 3
Why this works
Set locking_mode=EXCLUSIVE if single-writer access is guaranteed.
What not to do
Why it's wrong:
Sources
📚 Official docs: https://www.sqlite.org/rescode.html#ioerr_lock
🔧 Source ref: sqlite3.h — SQLITE_IOERR_LOCK = 3850
📖 Further reading: SQLite file locking
Confidence assessment
⚠️ MEDIUM confidence
Stable.
See also
🔗 Related errors
📄 Reference pages