问题现象：突如其来的写入限制

上周在客户现场部署一个Drupal 9小型项目时，我遇到了一个看似简单却令人头疼的问题——当系统尝试保存内容或更新配置时，前端突然显示"attempt to write a readonly database"错误。这个使用SQLite作为数据库的轻量级项目，原本运行良好，却在关键时刻"罢工"了。

这种错误通常发生在系统尝试修改数据库内容时，SQLite引擎无法完成写入操作。与MySQL不同，SQLite直接将数据库存储为单一文件，这使得权限管理变得更为直接但也更容易出现问题。

深入分析：为什么数据库会"只读"？

经过半小时的排查，我发现了几个可能导致此问题的常见原因：

1. 文件系统权限问题（最常见）

   
   
   
   • SQLite数据库文件（通常位于web/sites/default/files/.ht.sqlite）或其目录缺少写入权限
   • PHP进程用户（如www-data）没有对文件的写权限

2. SELinux上下文限制（Linux系统特有）

   
   
   
   • 在启用SELinux的系统上，安全上下文可能阻止PHP进程访问数据库文件

3. 挂载点权限问题

   
   
   
   • 如果数据库文件位于特定挂载点（如NFS共享），挂载参数可能限制了写入权限

4. 文件锁定冲突

   
   
   
   • 其他进程可能已锁定数据库文件，导致写操作失败

5. 配置错误

   
   
   
   • 错误的settings.php配置可能导致Drupal以只读模式打开数据库

解决方案一：基础权限修复

第一步：确认文件位置与权限

bash

找到SQLite数据库文件位置

ls -lh web/sites/default/files/.ht.sqlite

检查权限设置

ls -ld web/sites/default/files/

正常情况应该显示类似：
-rw-rw-r-- 1 www-data www-data 1.5M Jun 10 15:30 .ht.sqlite drwxrwxr-x 3 www-data www-data 4.0K Jun 10 15:30 files/

修复命令示例：

bash

修正文件权限

chmod 664 web/sites/default/files/.ht.sqlite
chmod 775 web/sites/default/files/

修正所有权（根据实际PHP用户调整）

sudo chown www-data:www-data web/sites/default/files/.ht.sqlite
sudo chown -R www-data:www-data web/sites/default/files/

解决方案二：处理SELinux限制

对于使用SELinux的系统（如CentOS/RHEL），需要额外步骤：

bash

检查当前上下文

ls -Z web/sites/default/files/.ht.sqlite

临时允许访问

sudo chcon -R -t httpdsysrwcontentt web/sites/default/files/

永久解决方案（需要适当策略）

sudo semanage fcontext -a -t httpdsysrwcontentt "/path/to/site(/.*)?"
sudo restorecon -Rv /path/to/site

解决方案三：Drupal特定配置调整

在settings.php中，可以添加以下配置确保正确连接：

php $databases['default']['default'] = [ 'database' => 'sites/default/files/.ht.sqlite', 'prefix' => '', 'namespace' => 'Drupal\\sqlite\\Driver\\Database\\sqlite', 'driver' => 'sqlite', 'auto_prefix' => FALSE, // 增加以下参数 'pdo' => [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_TIMEOUT => 30, ], ];

解决方案四：替代方案与高级技巧

如果上述方法无效，可以考虑：

1. 数据库文件迁移
   bash mv web/sites/default/files/.ht.sqlite /var/lib/sqlite/ chown www-data:www-data /var/lib/sqlite/.ht.sqlite
   然后在settings.php中更新路径

2. 使用SQLite WAL模式
   在settings.php中添加：
   php $databases['default']['default']['init_commands'] = [ 'wal' => 'PRAGMA journal_mode=WAL;', ];

3. 临时切换存储引擎
   php $settings['tempstore'] = 'database'; // 替代默认的文件存储

预防措施：避免问题再次发生

1. 部署时自动化权限设置bash

   
   
   

   在部署脚本中加入

   
   
   

   install -d -m 775 -o www-data -g www-data web/sites/default/files

2. 监控文件属性变化bash

   
   
   

   使用inotifywait监控文件变化

   
   
   

   inotifywait -m -e attrib web/sites/default/files

3. 定期维护
   sql -- 定期执行VACUUM优化数据库 PRAGMA vacuum;

经验总结：为什么SQLite适合Drupal小型项目

尽管遇到这个权限问题，SQLite仍然是Drupal小型项目的优秀选择，因为：
- 零配置部署
- 单文件备份简单
- 性能在低流量场景足够
- 不需要单独数据库服务

关键是要正确设置环境权限，并在部署文档中明确记录这些步骤。通过这次故障解决，我完善了团队的部署检查清单，新增了SQLite权限验证环节，避免了类似问题的重复发生。

最终验证

解决问题后，建议执行以下验证步骤：
1. 创建测试内容并保存
2. 更新系统配置
3. 检查最近日志（/admin/reports/dblog）
4. 确认数据库文件更新时间：
bash stat web/sites/default/files/.ht.sqlite

通过系统化的排查和解决，这个"readonly database"错误完全可以被彻底根治。