Application writes to its SQLite database fail with SQLITE_READONLY, attempt to write a readonly database, though the file itself shows writable permissions when I check it.
Linux server, the app runs under its own service account. What am I missing?
The file being writable is only a third of what SQLite needs, which is exactly the trap. The checklist that finds it:
The directory, the usual culprit: SQLite writes its journal or WAL files beside the database in the same directory, so the service account needs write permission on the directory rather than just the file. A writable file in an unwritable directory produces precisely your error. Check with sudo -u serviceaccount touch /path/to/dir/test and delete the test on success.
The companion files second: if the database ever ran under a different account, root during a migration classically, the leftover -wal and -shm files beside it may belong to that account, blocking the service account's writes while the main file looks fine. ls -la the directory and chown the companions to match, or with the app stopped, let a clean open recreate them.
The remaining suspects when both pass: the connection string opening the database with a read only flag, mode=ro or the SQLITE_OPEN_READONLY flag in code, worth grepping the config for. A filesystem mounted read only, mount | grep the path tells you. And the immutable attribute on the file itself, lsattr showing i, rare but maddening when present.
The -wal file belonged to root from last month's migration script, exactly the second check. Chowned it and writes flow. The directory permission explanation also fixed my mental model of what SQLite actually touches.