SQLite 原目录报 readonly，复制到其他目录却能写：检查目录权限与 UAC

SQLite 的 .db 文件能打开、能查询，但保存修改时报 attempt to write a readonly database。同一份数据库放到另一个目录能写，放回原目录又失败时，应先检查运行程序的身份、数据库文件和所在目录的权限。文件内容损坏不能仅凭这个报错确定。

Windows 上还有一种容易误判的情况：账户属于 Administrators 组，但 DB Browser for SQLite 普通启动失败，以管理员身份启动却能写。这支持继续检查有效权限和 UAC，不意味着以后都应让数据库工具以管理员身份运行。

查实际打开的位置与运行身份

先在工具中确认数据库的完整路径，排除打开了同名副本。连接允许执行查询时，可以查看以下信息；它们是供读者使用的检查示例：

PRAGMA database_list;
PRAGMA journal_mode;

database_list 列出连接实际使用的数据库，journal_mode 帮助判断相关日志文件。目录移动会改变权限继承和应用访问条件，因此“复制后正常”只是位置相关的线索，不是数据库本身正常的完整证明。

在 Windows 文件属性的“安全”页检查实际用户的有效访问权限，同时检查目录、数据库文件及已经存在的辅助文件。服务或计划任务使用的账户可能与当前桌面用户不同，给登录用户授权也不会自动覆盖服务账户。

UAC 启用时，管理员组成员启动普通应用通常仍使用经过限制的访问令牌。经授权的管理员可用一次提升权限的启动作对照；提升后恢复写入，就应检查哪些访问仅在管理员令牌下允许。不要把关闭 UAC 当作修复，也不要把整套服务改为管理员运行。

SQLite 写事务通常还需要管理同目录的辅助文件。回滚日志常见名称为 app.db-journal；WAL 模式可能使用 app.db-wal 和 app.db-shm。这里的 app.db 是示例名称。

只检查 .db 文件上的写权限不够。程序可能无法在目录创建日志，或无法访问另一个账户此前创建的日志文件。如果应用能提供扩展错误码，SQLITE_READONLY_DIRECTORY 指向无法在数据库目录创建所需日志的情况。普通 readonly 报错本身没有这么精确，仍须核对实际权限。

记录原有权限后，由管理员为真正需要写数据库的账户配置必要的文件和目录访问，或选择该账户可管理的专用数据目录。调整范围限于相应数据库目录，保留其他账户的隔离；需要回退时恢复已记录的 ACL 和应用路径。

若迁移数据目录，先停止相关写入并关闭连接，采用可靠备份或应用支持的迁移方式。修改应用数据库路径后重新确认实际打开的是新位置。不要在仍有事务活动时只复制一个 .db 文件，尤其是 WAL 中可能还有未合并的数据。

看到 -journal 或 -wal 文件，不等于它是可以清理的垃圾。崩溃后的日志可能包含恢复数据库需要的信息，删除、改名或与数据库拆开都可能破坏恢复。

恢复所需的写权限后，让 SQLite 正常打开并处理恢复。若仍报只读，再检查工具是否按只读方式打开、连接 URI 是否指定只读，以及存储卷是否只读。不能在没有依据时关闭日志模式来绕过目录权限。

修复的标准是：使用原计划的普通用户或服务账户，连接预期路径，完成一次获准的业务写入并提交，关闭后重新打开仍能读取结果。以管理员身份启动成功，只是诊断线索；只有正常运行身份恢复，才说明日常使用条件已满足。