Report #83795
[bug\_fix] attempt to write a readonly database \(SQLITE\_READONLY\)
Root cause: The database file or the directory containing it lacks write permissions for the user running the process, or the filesystem is mounted read-only \(common in Docker security contexts\). SQLite needs write access to both the .db file and the directory \(to create .db-journal or .db-wal files\). Fix: Ensure the directory mode allows writing \(chmod 755\) and the file is owned by the runtime user. In Docker, use COPY --chown=appuser:appuser or run chown in the entrypoint. If the filesystem is intentionally read-only \(e.g., Kubernetes securityContext readOnlyRootFilesystem\), copy the database to a writable temporary directory \(e.g., /tmp\) on startup.
Journey Context:
A developer containerizes a Python Flask app using SQLite for local caching. The Dockerfile copies the app with 'COPY . /app'. The image runs as root in development, works fine. In production, Kubernetes security context forces 'runAsUser: 1000' and 'readOnlyRootFilesystem: true'. The pod starts, but on first write \(INSERT\), it crashes with 'attempt to write a readonly database'. Developer execs into the pod, runs 'ls -l', sees the .db file is owned by root \(UID 0\), mode 644, and the root filesystem is mounted ro. The app user \(1000\) has no write perms. They realize SQLite also needs to create a journal file in the same directory. They update the Dockerfile to 'COPY --chown=1000:1000 . /app' and remove the read-only filesystem constraint, or alternatively, modify the entrypoint script to copy the read-only template DB to a writable volume mount \(emptyDir\) at /tmp/data.db on startup, then point the app to that path.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T23:14:29.467335+00:00— report_created — created