Error operativo: bash de escribir una base de datos de solo lectura en el servidor ubuntu

Estoy ejecutando un FlaskApp usando mod_wsgi y apache2 en el servidor Ubuntu. Intenté ejecutar la aplicación flask en localhost éxito y luego la implementé en el servidor de ubuntu.

Pero cuando trato de actualizar la base de datos, está dando un error: Failed to update model. (OperationalError) attempt to write a readonly database u'UPDATE mysongs SET songurl=? WHERE songid.id = ?' (u'www.site.com/I_wanna_dance', 1) Failed to update model. (OperationalError) attempt to write a readonly database u'UPDATE mysongs SET songurl=? WHERE songid.id = ?' (u'www.site.com/I_wanna_dance', 1)

Ahora intenté buscar el permiso del archivo de la base de datos que es: -rwxr-xr-x 1 www-data www-data 10240 Jul 14 15:35 /var/www/mywebsite/appfolder/appdata.db

Cuando bash cambiar el permiso a 777, 755, 644, etc., se muestra otro error: unable to open database file Aunque el archivo de la base de datos funciona bien con el permiso 644 en localhost pero no en el servidor de Ubuntu.

También verifiqué el permiso de los directorios y para /var /var/www /var/www/mywebsite /var/www/mywebsite/appfolder etc., todos tienen www-data:www-data como su nombre de usuario y grupo de propietarios.

Traté de buscar en Google y no tengo otra solución que no sea la sugerencia de cambiar los permisos de archivo / dir, que yo mismo he probado.

¿Por qué no puede leer / acceder al archivo de base de datos?

Por favor recomiende.

Resuelto el problema. Fue debido a conflicto de permiso de archivo de base de datos.

Este problema está relacionado con la administración de permisos de archivos Y principalmente con el usuario elegido en el archivo de configuración de Apache ( *.conf ) definido para contener los procesos de la aplicación. En pocas palabras: los permisos de escritura deben coincidir con este usuario.

La mayoría de las veces, el archivo de base de datos sqlite ha sido creado por un usuario específico (por ejemplo, su usuario actual) y la aplicación del sitio se ejecuta bajo procesos secundarios iniciados por el usuario predeterminado de Apache www-data (si no se especificó el parámetro user dentro de la directiva WSGIDaemonProcess ). En este caso, la base de datos puede leerse pero generará este error si intenta modificar algo:

(OperationalError) intenta escribir una base de datos de solo lectura …

porque www-data no tiene permiso en el archivo (o en la carpeta principal)


Primera forma: aplicar permisos al usuario www-data.

Puede establecer los permisos de escritura en el archivo de base de datos y su carpeta principal.

Si la carpeta contiene otros archivos, puede agregar permiso de escritura en ella y solo cambiar la propiedad del archivo de base de datos a los datos de www del usuario, por ejemplo:

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

O si la carpeta solo contiene el archivo de base de datos, puede intentar cambiar el propietario de la carpeta directamente:

 sudo chown -R www-data: db_directory 

Luego verifique que los permisos de lectura / escritura estén bien establecidos (con ls -l site_database.db )

Más ayuda en este post.


Otra solución: agregue un usuario específico para mantener los procesos de la aplicación

Esto se puede hacer dando los parámetros de user y group en la directiva WSGIDaemonProcess en la configuración de Apache. Hará que Apache inicie los procesos secundarios bajo un usuario específico.

Por ejemplo :

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

Este usuario gestionará todas las operaciones, incluida la lectura / escritura en cualquier archivo, así que verifique que tenga todos los permisos necesarios en todos los archivos relacionados.

Por motivos de seguridad, no puede utilizar un usuario con amplios privilegios.

Algunos comentarios pueden ayudar en esta publicación .


Nota : tenga cuidado si administra sus propios archivos de registro con directivas como ErrorLog en la configuración de Apache, estos archivos seguirán la misma lógica de permisos. Lo mismo para cualquier archivo que pueda ser cambiado por la aplicación.