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

Posted 2023-02-16

【中文标题】将 SQLite 数据库模式更改为读写

【英文标题】：Change SQLite database mode to read-write

【发布时间】：2010-12-03 20:58:46

【问题描述】：

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

当我执行更新语句时，我总是得到：

SQL 错误：尝试写入只读数据库

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

【问题讨论】：

运行 sqlite3 的用户（或者你用来执行查询的任何东西）是否对数据库有写权限？您是否仔细检查过文件所有权？

我确定他们有权这样做。

我在一个网络应用程序中看到了这一点，我忘记在数据库文件上设置 GID 并且“www-data”帐户（Apache 运行在该帐户下）被拒绝对该文件的写访问权限。

【参考方案1】：

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

多个进程同时打开数据库 (see the FAQ)。

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

最后，another FAQ 说：“确保包含数据库文件的目录对于执行 CGI 脚本的用户也是可写的。”我认为这是因为引擎需要在目录中创建更多文件。

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

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

【讨论】：

我将出价放在第三个项目符号上 - 包含 DB 文件的目录也应该是可写的，因此可以创建锁定文件。

我的第一颗子弹：D

最后一个。我总是忘记 sudo ：P

我可以添加到这个列表中：数据库文件在使用过程中被替换。我不想解释导致这个结论的愚蠢。

这应该被标记为答案。在我的情况下（桌面应用程序），它与 Windows 压缩数据库有关，因为主硬盘空间太小。我认为 windows 会询问用户是否要压缩文件以获得空间，如果用户说是，那么可能会出现只读数据库问题。

【参考方案2】：

我通过将 /db 目录上所有文件的所有者从 root 更改为我来解决这个问题。

只需在该文件夹上执行ls -l，如果任何文件管理器归root 所有，只需将其更改为您，使用：sudo chown user file

【参考方案3】：

（此错误消息通常具有误导性，通常是一般权限错误）

在 Windows 上

如果您直接针对数据库发出 SQL，请确保您用于运行 SQL 的任何应用程序都以管理员身份运行 如果应用程序正在尝试更新，它用来访问数据库的帐户可能需要对包含您的数据库文件的文件夹的权限。例如，如果 IIS 正在访问数据库，则 IUSR 和 IIS_IUSRS 可能都需要适当的权限（您可以通过暂时让这些帐户完全控制文件夹来尝试这样做，检查是否可行，然后酌情绑定权限）李>

【讨论】：

我必须以管理员身份运行“DB Browser”。

我在 Windows 10 上将“完全控制权”授予“所有人”，但它仍然无法正常工作。但是，正如@EbenRoux 所说，您可能还需要以管理员身份运行“DB Browser”，这使它对我有用。

【参考方案4】：

当您的数据库已被一个应用程序访问，而您正尝试使用另一个应用程序访问它时，通常会发生此错误。

【讨论】：

为什么要尝试从另一个数据库访问一个数据库？

我认为他的意思是来自另一个应用程序

【参考方案5】：

如果使用 Android。

确保您已将写入您的EXTERNAL_STORAGE 的权限添加到您的androidManifest.xml。

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

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

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

【讨论】：

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

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

【参考方案6】：

在 Linux 命令 shell 中，我做了：

chmod 777 <db_folder>

其中包含数据库文件。

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

【讨论】：

安全隐患是什么？

这和adrian's answer有什么不同？

它可以作为快速解决方案，但需要稍后挖掘以获得更好的安全解决方案

这会将所有权限授予所有用户，从安全角度来看，这可能不是您想要的。

【参考方案7】：

分享我遇到的这个错误的个人经验，最终解决了这两个问题。可能不一定与您的问题有关，但似乎此错误非常普遍，可以归因于数不胜数的事情。

数据库实例在另一个应用程序中打开。我的数据库似乎处于“锁定”状态，因此它转换为只读模式。我能够通过停止共享数据库的应用程序的第二个实例来追踪它。

目录树权限 - 请务必确保用户帐户不仅具有文件级别的权限，还具有整个上级目录级别的权限，一直到 / 级别。

谢谢

【参考方案8】：

我今天也遇到了这个问题。

这是由 Windows Mobile 上的 ActiveSync 引起的 - 我正在使用的文件夹已同步，因此 AS 进程不时抓取 DB 文件导致此错误。

【参考方案9】：

在 Windows 上：

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

我们的系统遇到了这个问题，这绝对不是权限问题，因为程序本身大部分时间都能够以可写的方式从多个线程打开数据库，但偶尔会（仅在 Windows 上，而不是在OSX），即使程序中的所有其他线程都没有问题，一个线程也会出现这些错误。

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

成功了；显然只需要有足够的时间将资源刷新到磁盘。

【参考方案10】：

在 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>

【讨论】：

您只是更改了 group，而不是 user（这很好，并且可能比更改用户 更好 ，但您的回答具有误导性）。

是什么让您认为该文件应该属于 Apache 用户/组？

如果你把数据库文件放在你的 web 项目目录中，这个文件应该总是由用户而不是 Apache 或 nginx 拥有，否则你将阻止登录用户自己修改该文件

【参考方案11】：

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

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

在我的 SELinux 管理 GUI（在 Fedora 19 上）中，我选中了标有 httpd_unified（统一 HTTPD 处理所有内容文件）行上的复选框，然后就可以开始了。

【讨论】：

谁的读/写权限？

如何检查和设置？

【参考方案12】：

我在 ESP32 上使用 SQLite，这里的所有答案都是“非常奇怪”.... 当我查看 ESP 闪存上的数据时，我注意到整个数据库只有一个文件（还有一个临时文件）。

在这个 db 文件中，我们当然有用户表，但也有系统表，例如“sqlite_master”，其中包含表的定义。 所以，似乎很难相信这可能是一个“chmod”问题，因为如果文件是只读的，即使创建表也是不可能的，因为 SQLite 将无法写入“sqlite_master”数据...... 所以我认为我们的朋友 user143482 正在尝试访问“只读”表。在 SQLite 源代码中，我们可以看到一个名为 tabIsReadOnly 的函数，其中包含以下注释：

 /* Return true if table pTab is read-only.
 **
 ** A table is read-only if any of the following are true:
 **
 **   1) It is a virtual table and no implementation of the xUpdate method
 **      has been provided
 **
 **   2) It is a system table (i.e. sqlite_master), this call is not
 **      part of a nested parse and writable_schema pragma has not 
 **      been specified
 **
 **   3) The table is a shadow table, the database    connection is in
 **      defensive mode, and the current sqlite3_prepare()
 **      is for a top-level SQL statement.
 */

【参考方案13】：

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

自动启动 TeamSpeak：作为您的非 root 帐户 crontab -e @reboot /path to ts3server/ aka /home/ts3server/ts3server_startscript.sh start

【参考方案14】：

在项目路径终端 django_project#

sudo chown django:django *

【参考方案15】：

在win10系统崩溃后，尝试用DB Browser打开db，但只读。 只需删除日志文件即可。

【参考方案16】：

经过数小时的反复试验，我解决了我的问题。尽管我已经更改了我的权限（遗憾的是，我也使用了chmod 777 db.sqlite3），但问题完全是另外一回事。

这东西终于奏效了（可能是因为我用过bitnami）

$ chown :daemon /path/to/your/sqlite/file

$ chmod 664 /path/to/your/sqlite/file

$ chown :daemon /path/to/your/project

$ chmod 775 /path/to/your/project

【参考方案17】：

"chmod 777 databasefilename" 在我的 debian 10 上运行良好学分：Dennis “chmod 775 databasefilename”是错误的原因

【参考方案18】：

删除数据库日志文件 就我而言，它是：sudo rm universal3a.db-journal

【讨论】：

这应该是一条评论

【参考方案19】：

在命令行中，进入你的数据库文件所在的文件夹，执行以下命令：

chmod 777 databasefilename

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

【讨论】：

这很糟糕。

完美答案！

它可能会解决这个问题，但不建议这样做，因为它可能会导致安全问题。

Linux 上的整个权限系统造成的安全问题多于保护