Changing read-write SQLite database mode

How can I modify a read-only SQLite database to read-write?

When I ran the update statement, I always got:

SQL error: attempt to write read-only database

An SQLite file is a writable file in the file system.

+80
sqlite sqlite3
Oct 05 '09 at 7:52
source share
14 answers

This error message may have several reasons:

  • In several processes, the database is open at the same time ( see FAQ ).

  • There is a plugin for compressing and encrypting the database. This does not allow changing the database.

  • Finally, another FAQ says: "Make sure the directory containing the database file is also writable by the user running the CGI script." I think this is because the engine should create more files in the directory.

  • The entire file system may be read-only, for example, after a crash.

  • On Unix systems, another process can replace the entire file.

+66
Oct 05 '09 at 8:06
source share

I solved this by changing the owner from root to me for all the files in the db directory. db.

Just do ls -l in this folder, if any of the files is root , just change it for you using: sudo chown user file

+5
Jun 09 '13 at 13:42 on
source share

When using Android.

Make sure you add write permission to EXTERNAL_STORAGE to your AndroidManifest.xml .

Add this line to your AndroidManifest.xml file above and outside your <application> .

 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 

This will allow your application to write to the SD card. This will help if your EXTERNAL_STORAGE is where you saved your database on the device.

+4
Feb 29 '12 at 10:43
source share

This error usually occurs when one application is accessing your database and you are trying to access it using another application.

+3
Jan 01 '13 at 3:25
source share

I had this problem today.

This is caused by ActiveSync on Windows Mobile - the folder I was working in was synchronized, so the AS process grabbed the DB file from time to time, causing this error.

+2
Feb 27 '12 at 17:15
source share

On the Linux command line, I did:

 chmod 777 <db_folder> 

Where is the database file.

It works. Now I can access my database and insert queries.

+2
May 29 '14 at 23:21
source share

(this error message is usually misleading and is usually a common permission error)

In windows

  • If you use SQL directly for the database, make sure that the application that you use to run SQL runs as an administrator
  • If the application is trying to upgrade, the account used to access the database may need permissions on the folder containing your database file. For example, if IIS accesses the database, IUSR and IIS_IUSRS may both require appropriate permissions (you can try this by temporarily giving these accounts full control over the folder, checking to see if it works, then linking the permissions accordingly)
+2
Jul 24 '18 at 8:24
source share

On Linux, give read and write permissions to the entire folder containing the database file.

In addition, SELinux can block recording. You must set the correct permissions.

In my SELinux GUI (in Fedora 19), I checked the field in a line labeled httpd_unified (Unify HTTPD processing of all content files), and I was good to go.

+1
Nov 13 '14 at 16:17
source share

To share personal experience, I came across this error, which eventually fixed both. Perhaps this is not necessarily related to your problem, but it seems that this error is so general that it can be attributed to different things.

  1. The database instance is open in another application. My database was in a locked state, so it went into read-only mode. I managed to track it by stopping the second instance of the application sharing the database.

  2. Directory tree permission - make sure that the user account has permission not only at the file level, but at the entire top level of directories up to / level.

thank

+1
Sep 17 '18 at 2:56
source share

At the command prompt, enter the folder in which the database file is located, and run the following command:

 chmod 777 databasefilename 

This will grant all permissions to all users.

0
Aug 05 '11 at 18:38
source share

On Windows:

tl; dr: try opening the file again.

Our system suffered from this problem, and it was definitely not a permission problem, since the program itself could open the database as many times as possible from many streams, but sometimes (only on Windows, not OSX), the stream would get these errors, although all other threads in the program did not have any difficulties.

In the end, we found that the downstream flows were only those that tried to open the database immediately after another thread closed it (within 3 ms). We suggested that the problem is that Windows (or the sqlite implementation under windows) does not always immediately clear file resources after closing the file. We got around this by running a test write request to db on opening (for example, creating then dropping a table with a dumb name). If creation / crash did not succeed, we waited 50 ms and tried again, repeating until it was executed, or 5 seconds passed.

It worked; apparently, it just needed enough time for the resources to get them to disk.

0
Jun 22 '17 at 21:32
source share

In the way of the project Terminal django_project #

 sudo chown django:django * 
0
Jun 05 '18 at 13:48
source share

Edit the DB: I am having problems editing db. I ended up having sudo chown 'non root username' ts3server.sqlitedb
until it was root, I could edit the file. Username is the account of my non root account.

TeamSpeak auto-launch: how is your account without root

crontab -e
@ reboot / path to ts3server / aka / home / ts3server / ts3server_startscript.sh start

-one
Jan 21 '16 at 19:34
source share

In Ubuntu, change the owner to the Apache group and grant the necessary permissions (no, it's not 777):

 sudo chgrp www-data <path to db.sqlite3> sudo chmod 664 <path to db.sqlite3> 

Update

You can also set permissions for the group and user.

 sudo chown www-data:www-data <path to db.sqlite3> 
-one
Oct 18 '16 at 15:36
source share



All Articles