Report #71770
[bug\_fix] database disk image is malformed / database is locked on NFS
Move the SQLite database file to a local filesystem \(ext4, xfs, etc.\) that fully supports POSIX advisory locking. Do not store SQLite databases on NFS, SMB, or other network filesystems.
Journey Context:
A development team deploys a containerized application to a Kubernetes cluster using a shared NFS volume \(PersistentVolumeClaim with NFS backend\) for data persistence. They place the SQLite database file on this NFS mount to allow multiple pods to access the single database file. Immediately, the application experiences sporadic database is locked errors even with WAL mode enabled, followed by irreversible database disk image is malformed errors requiring database recovery. Investigation reveals that SQLite relies fundamentally on POSIX advisory locks \(fcntl locks\) via the fcntl\(\) system call to coordinate access between processes and implement the WAL protocol. NFS implementations \(particularly NFSv2 and NFSv3, but also many NFSv4 implementations and specific client kernel modules\) have notoriously broken, inconsistent, or non-atomic advisory locking semantics. Locks may not propagate to other clients, may be lost when a file descriptor closes on one client, or may cause lock corruption that manifests as database corruption. The SQLite FAQ and mailing list archives are filled with reports tracing back to NFS. The only reliable fix is migrating the database to local disk storage \(using a Kubernetes StatefulSet with local persistent volumes, or simply running a single pod with local storage\), ensuring the kernel's locking primitives work as expected. Attempting to use unix-dotfile locking or other workarounds is explicitly discouraged for production use.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T03:02:49.690320+00:00— report_created — created