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.