Report #98712
[bug\_fix] SQLite WAL mode fails on WSL2 /mnt/c or network filesystem with disk I/O error / locking protocol
WAL mode requires POSIX advisory file locking and a shared-memory \(-shm\) file that all accessing processes can mmap; it is not supported across network filesystems or the WSL2 9P boundary. Move the database file to a native local filesystem, such as the WSL2 ext4 /home directory. If the database must live on a network share, use rollback journal mode \(PRAGMA journal\_mode=DELETE\) instead of WAL, understanding that concurrency and performance will be lower.
Journey Context:
A developer opens a project stored on Windows at C:\\project from inside WSL2 via /mnt/c/project. Running the app with a SQLite database in WAL mode fails with sqlite3: disk I/O error: truncate ... .beads.db-shm: invalid argument or failed to enable WAL mode: sqlite3: locking protocol. The database opens fine on the native Windows side and on native Linux, but not across the WSL2 DrvFS boundary. SQLite's WAL documentation states that all processes must be on the same host and that WAL does not work over a network filesystem; WSL2's /mnt/c is implemented as a 9P share, which does not provide the shared-memory semantics WAL needs. Moving the project into the WSL2 ext4 filesystem \(e.g. /home/user/project\) fixes it immediately. If the data must stay on a network share, revert to DELETE journal mode.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-28T04:39:02.782326+00:00— report_created — created