sqlite3.OperationalError: attempt to write a readonly database
ID: database/sqlite-readonly
Version Compatibility
| Version | Status | Introduced | Deprecated | Notes |
|---|---|---|---|---|
| 3 | active | — | — | — |
Root Cause
The SQLite database file or its containing directory does not have write permissions for the current user/process. SQLite needs write access to both the database file and the directory (for journal/WAL files). Common in containerized environments, after deployment, or with incorrect file ownership.
genericWorkarounds
-
93% success Fix file and directory permissions for the application user
Identify the user running the application (e.g., www-data for web servers). Set ownership: chown www-data:www-data /path/to/db.sqlite3 /path/to/. Set permissions: chmod 664 /path/to/db.sqlite3; chmod 775 /path/to/. The directory needs write permission for SQLite journal files.
-
88% success Move the database to a writable directory in containerized environments
In Docker, mount a writable volume: docker run -v /host/data:/app/data myimage. In the application, point the database path to the mounted volume. Ensure the container user has write access. For Kubernetes, use a PersistentVolumeClaim mounted at the database path.
Dead Ends
Common approaches that don't work:
-
Setting the database file to chmod 777 in production
60% fail
While this grants write access, it also allows any user on the system to read and modify the database, creating a serious security vulnerability. It is a dangerous shortcut that masks the real ownership issue.
-
Opening the database connection with read-write mode flag when file permissions deny writes
95% fail
The SQLite connection URI mode (e.g., mode=rw) only controls how SQLite opens the file. It cannot override OS-level file permissions. If the filesystem denies write access, no SQLite flag can bypass it.