Report #53354
[bug\_fix] attempt to write a readonly database \(SQLite permissions\)
Ensure the database file, the containing directory, and the -wal/-shm files are all owned by the user running the application process \(e.g., \`chown www-data:www-data /path/to/db\*\`\) and have write permissions \(664\). Root cause is usually the database file being created by root \(via sudo migration command\) but read by www-data, or the directory being read-only preventing SQLite from creating journal/WAL temporary files \(-wal, -shm\) required for writing.
Journey Context:
You deployed a Django app with SQLite on Ubuntu with Nginx/Gunicorn. It works perfectly in development \(runserver\), but in production every write operation throws "sqlite3.OperationalError: attempt to write a readonly database". You check the .db file permissions with \`ls -l\` and see it's 644 and owned by www-data, which looks correct. You verify the disk isn't full. You check if the filesystem is mounted read-only \(it's not\). You try running the gunicorn process as root and suddenly it works, confirming it's a permission issue, but you can't run as root in production. You run \`ls -la\` on the directory containing the .db file and notice the .db-wal and .db-shm files \(created because you enabled WAL mode\) are owned by root with permissions 644. When you previously ran a management command with \`sudo\`, it created these files as root. The www-data user can write to the .db file but cannot write to the root-owned -wal file, causing the readonly error. You run \`chown -R www-data:www-data /path/to/db/directory/\` to fix ownership, and the error disappears. The fix works because SQLite requires write access to the main file, the directory \(for lock files\), and all associated WAL/journal files.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T20:03:00.381031+00:00— report_created — created