OperationalError: attempt to write a readonly database in ubuntu server

This issue is related to the files permissions management AND mostly to the user chosen in the Apache configuration file (*.conf) defined to holds the application processes. In a few words : the write permissions need to match this user.

Most of the time, the sqlite database file has been created by a specific user (for example your current user) and the site application is running under child processes launched by the Apache default user www-data (if the parameter user wasn't specified inside the directive WSGIDaemonProcess). In this case, the database can be read but it will throw this error if you try to modify anything :

(OperationalError) attempt to write a readonly database...

because www-data has no permission on the file (or on the parent folder)


First way : Apply permissions to the user www-data

You can set the write permissions on the database file and its parent folder.

If the folder contains other files, you can add write permission on it and only change the ownership of the database file to the user www-data, for example :

sudo chmod o+w db_directory
sudo chown www-data:  db_directory/site_database.db 

Or if the folder contains only the database file, you can try to change the folder owner directly :

sudo chown -R www-data: db_directory

Then check that read/write permissions are well set (with ls -l site_database.db)

More help in this post.


Other solution : Add a specific user to hold the application processes

This can be done by giving the user and group parameters in the directive WSGIDaemonProcess in Apache configuration. It will make Apache launch the child processes under a specific user.

For example :

...
WSGIDaemonProcess main user=myuser group=myuser threads=3 python-home=/path/to/the/virtualenv/
WSGIProcessGroup main
WSGIApplicationGroup %{GLOBAL}
...

This user will manage all operation, including read/write to any files, so check that it has all needed permissions on every related files.

For security concerns, you may not use a wide-privileged user.

Some comments can help in this post.


Note : be careful if you manage your own logging files with directives like ErrorLog in the Apache configuration, these files will follow the same logic of permissions. The same for any file that could be changed by the application.


Resolved the issue. It was due to database file permission conflict.