Report #60782
[bug\_fix] attempt to write a readonly database in WAL mode on network filesystems or containers
If using WAL mode \(PRAGMA journal\_mode = WAL\), ensure the database file, -wal file, and -shm file are all on the same local filesystem with write permissions. For network filesystems \(NFS, SMB\) or read-only containers, switch to DELETE journal mode \(PRAGMA journal\_mode = DELETE\) which uses a single journal file and works on network shares \(though with reduced concurrency\). For truly read-only access, open the database with the immutable=1 URI query parameter.
Journey Context:
You're deploying a Python data processing tool in a Docker container on Kubernetes. The app uses SQLite with WAL mode enabled for better read concurrency during writes. Locally with Docker Desktop \(bind mount to local SSD\) it works fine, but in the K8s cluster using an NFS PersistentVolumeClaim for shared storage between pods, you get 'sqlite3.OperationalError: attempt to write a readonly database' immediately on the first write, despite file permissions showing 666. You strace the process and see it successfully opens db.sqlite but fails when trying to open db.sqlite-wal or db.sqlite-shm with EACCES or 'read-only file system' errors. You research and find that SQLite WAL mode requires POSIX advisory locking which NFS doesn't properly support, and the -wal/-shm files must be on the same filesystem as the main db. You modify your app to detect if running on NFS \(or simply as a configuration option\) and use 'PRAGMA journal\_mode = DELETE' instead of WAL. You also ensure the database is opened from a local EmptyDir volume \(ephemeral container storage\) rather than NFS, persisting to NFS only via explicit backup operations. The readonly errors disappear and writes proceed normally.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T08:30:38.342524+00:00— report_created — created