将SQLite数据库模式更改为可读写


101

如何将SQLite数据库从只读更改为读写?

当我执行更新语句时,我总是得到:

SQL错误:尝试编写只读数据库

SQLite文件是文件系统上的可写文件。


3
运行sqlite3的用户(或用于执行查询的任何用户)是否对数据库具有写权限?您是否仔细检查了文件所有权?
Tim Post

我确定他们有权这样做。
user143482

2
我在一个Web应用程序中看到了这一点,在该应用程序中我忘记在数据库文件上设置GID,并且“ www-data”帐户(Apache在其下运行)被拒绝对该文件进行写访问。
finnw

Answers:


86

此错误消息可能有多种原因:

  • 多个进程同时打开了数据库(请参阅FAQ)。

  • 有一个插件可以压缩和加密数据库。不允许修改数据库。

  • 最后,另一个常见问题解答说:“确保包含数据库文件的目录也对执行CGI脚本的用户可写。” 我认为这是因为引擎需要在目录中创建更多文件。

  • 整个文件系统可能是只读的,例如在崩溃之后。

  • 在Unix系统上,另一个进程可以替换整个文件。


26
我将出价放在第三个项目符号上-包含数据库文件的目录也应该是可写的,以便可以创建锁定文件。
威2009年

我的第一枚子弹:D
Vinay,2016年

最后一个。我总是忘了sudo:P
Storm

3
我可以添加到此列表:在使用过程中替换了数据库文件。我宁愿不必解释导致这一结论的愚蠢行为。
Wim Rijnders,

这应该被标记为答案。就我而言(一个桌面应用程序),它与Windows压缩数据库有关,这是由于主硬盘空间太小。我认为Windows将询问用户是否要压缩文件以获取空间(如果用户说是,那么可能会出现只读数据库问题)。
Nandostyle

10

我通过将/ db dir上所有文件的所有者从根目录更改为我来解决。

只需ls -l在该文件夹上执行操作即可,如果任何文件管理器归其所有,root只需使用以下命令将其更改为您sudo chown user file


5

当一个应用程序已经访问了您的数据库,而您试图通过另一个应用程序访问它时,通常会发生此错误。


为什么要尝试从另一个数据库访问数据库?
彼得·莫滕森

我认为他的意思是来自其他申请
amaurymartiny

4

如果使用Android。

确保您已添加写入权限, EXTERNAL_STORAGE到您的AndroidManifest.xml

将此行添加到AndroidManifest.xml文件的上方和下方<application>标签。

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

这将允许您的应用程序写入sdcard。如果您EXTERNAL_STORAGE将数据库存储在设备上,这将有所帮助。


这解决了我的问题。我修改了问题,以提供更多细节并更易于阅读。
prolink007,2012年

非常感谢。它也解决了我的问题。一票赞成:)
Altaf Sami 2013年

4

在Linux命令Shell中,我做了以下操作:

chmod 777 <db_folder>

其中包含数据库文件。

有用。现在,我可以访问我的数据库并进行插入查询。


安全隐患是什么?
彼得·莫滕森

这与阿德里安的答案有何不同?
彼得·莫滕森

1
它可以作为快速解决方案,但是需要在以后挖掘以寻求更好的安全解决方案
troydo42 '17

4
这将向所有用户授予所有权限,从安全角度来看,这可能不是您想要的。
Renel Chesak

3

(此错误消息通常具有误导性,通常是一般权限错误)

在Windows上

  • 如果直接针对数据库发布SQL,请确保用于运行SQL的任何应用程序都以管理员身份运行
  • 如果应用程序正在尝试更新,则它用来访问数据库的帐户可能需要包含数据库文件的文件夹的权限。例如,如果IIS正在访问数据库,则IUSR和IIS_IUSRS都可能需要适当的权限(您可以通过以下方式来临时获得这些帐户对文件夹的完全控制权,检查是否可行,然后适当地减少权限,以尝试这种方式)

1
我必须以管理员身份运行“ DB浏览器”。
Eben Roux

1
我在Windows 10上将“完全控制”权授予了“所有人”,但仍然无法正常工作。但是,正如@EbenRoux所述,您可能还需要以管理员身份运行“数据库浏览器”,这使其对我有用。
Peaceoutside

2

我今天也有这个问题。

这是由Windows Mobile上的ActiveSync引起的-我正在使用的文件夹已同步,因此AS进程有时会抓住DB文件,从而导致此错误。


1

在Linux上,对包含数据库文件的整个文件夹授予读/写权限。

另外,SELinux可能会阻止写入。您需要设置正确的权限。

在我的SELinux管理GUI(在Fedora 19上)中,我选中了标有httpd_unified(统一所有内容文件的HTTPD处理)的行上的框,我很高兴。


谁的读/写权限?
Peter Mortensen

如何检查和设置?
SynCap

1

为了分享个人经验,我遇到了此错误,最终将两者都修复了。不一定与您的问题有关,但此错误似乎太普遍了,可以归因于庞大的事物。

  1. 数据库实例在另一个应用程序中打开。我的数据库似乎处于“锁定”状态,因此它过渡到只读模式。通过停止共享数据库的应用程序的第二个实例,我能够对其进行跟踪。

  2. 目录树权限-请确保用户帐户不仅具有文件级别的权限,而且还具有直到/级别的整个上层目录的权限。

谢谢


1

在Ubuntu上,将所有者更改为Apache组并授予正确的权限(不,不是777):

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

更新资料

您还可以设置用户的权限。

sudo chown www-data:www-data <path to db.sqlite3>

4
您只是更改了 group,而不是用户(这很好,并且可能比更改用户更好,但您的答案具有误导性)。
Auspex

是什么使您认为该文件应属于Apache用户/组?
墨菲

0

在命令行中,输入数据库文件所在的文件夹,然后执行以下命令:

chmod 777 databasefilename

这将向所有用户授予所有权限。


22
这是很糟糕的。
Marco Kerwitz '16

完美的答案!
Jitesh Prajapati

它可以解决此问题,但不建议这样做,因为它可能导致安全问题。
凯西·拉哈

0

在Windows上:

tl; dr:尝试再次打开文件。

我们的系统遇到了这个问题,它绝对不是权限问题,因为程序本身大多数时候都可以从许多线程以可写的方式打开数据库,但偶尔(仅在Windows上,而不是在OSX上),即使程序中的所有其他线程都没有遇到困难,一个线程也会收到这些错误。

我们最终发现失败的线程只是那些试图在另一个线程关闭数据库后(3毫秒内)立即打开数据库的线程。我们推测该问题是由于Windows(或Windows下的sqlite实现)并不总是在关闭文件后立即清理文件资源这一事实造成的。通过在打开时对数据库运行测试写查询来解决此问题(例如,创建然后删除具有愚蠢名称的表)。如果创建/删除失败,我们等待50毫秒,然后重试,重复直到成功或5秒钟。

有效; 显然,只需要有足够的时间将资源刷新到磁盘。


-1

编辑数据库:编辑数据库时遇到问题。我最终不得不
sudo chown'non root username'ts3server.sqlitedb
,只要它不是root用户,我就可以编辑该文件。用户名是我的非root帐户的用户名。

自动启动TeamSpeak:作为您的非root帐户
crontab -e
@reboot / ts3server的路径/ aka /home/ts3server/ts3server_startscript.sh开始


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.