我刚才在远程服务器上使用存储在NFS挂载上的SQLite数据库时遇到了这个问题。当我使用的远程shell会话在数据库打开时崩溃后，SQLite无法获得锁。

上面建议的恢复方法对我不起作用(包括先移动然后再复制数据库的想法)。但是在将其复制到非nfs系统后，数据库变得可用，数据似乎没有丢失。

我的锁是由系统崩溃引起的，而不是由挂起进程引起的。为了解决这个问题，我简单地重命名了文件，然后将其复制回原来的名称和位置。

使用Linux shell将是:

mv mydata.db temp.db
cp temp.db mydata.db

我在一个场景中得到了这个错误，与这里描述的略有不同。

SQLite数据库位于由3个服务器共享的NFS文件系统上。在其中2个服务器上，我能够成功地对数据库运行查询，在第三个服务器上，我认为我得到了“数据库已锁定”消息。

第三台机器的问题是，在/var上没有剩余空间了。每次我试图在位于这个文件系统的任何SQLite数据库中运行查询时，我都得到了“数据库被锁定”的消息，并且在日志上出现了这个错误:

Aug 8 10:33:38 server01 kernel: lockd: cannot monitor 172.22.84.87

还有这个:

Aug 8 10:33:38 server01 rpc。statd[7430]: Failed to insert: writing /var/lib/nfs/statd/sm/other.server.name.com: No space left on device .日志含义 Aug 8 10:33:38 server01 rpc。statd[7430]: STAT_FAIL to server01 for SM_MON of 172.22.84.87

太空的情况处理好之后，一切都恢复正常了。

我有一个工具“DB Browser for SQLite”正在运行，也在里面工作。显然，这个工具也会锁上东西。 在点击“写入更改”或“恢复更改”后，锁消失了，另一个进程(一个React-Native脚本)不再给出这个错误。

根据我的经验，此错误是由以下原因引起的:您打开了多个连接。

例如:

1个或多个sqlitebrowser (GUI) 一个或多个电子线 rails线程

我不确定SQLITE3如何处理多线程/请求的细节，但当我关闭sqlitebrowser和电子线程时，rails运行良好，不会再阻塞了。

如果一个进程在SQLite DB上有一个锁，并且崩溃了，那么这个DB将永远处于锁定状态。这就是问题所在。并不是其他进程有锁。