DaWarIch项目中的Redis持久化权限问题分析与解决方案

背景介绍

在DaWarIch项目0.21.2版本的Docker部署环境中，用户报告了一个关于Redis服务无法写入磁盘的权限问题。这个问题表现为Redis后台保存数据时出现"Permission denied"错误，导致Redis进入保护模式，拒绝所有可能修改数据集的命令。

问题现象

当用户使用bind mounts(绑定挂载)方式部署DaWarIch时，Redis容器日志中会显示以下错误信息：

Failed opening the temp RDB file temp-233.rdb (in server root dir /data) for saving: Permission denied
Background saving error

同时，Sidekiq工作进程也会报告Redis配置为保存RDB快照但当前无法持久化到磁盘的错误。

技术分析

1. 文件系统权限问题

从用户提供的目录列表可以看出，Redis试图写入的shared目录的所有权可能存在问题。该目录的UID被设置为999，这通常对应于PostgreSQL容器中的postgres用户，而Redis容器默认使用redis用户(通常UID为999或1000)运行。

2. 共享卷设计问题

用户配置中，Redis和PostgreSQL两个服务共享了同一个绑定挂载目录${SHARED_DIR}。这种设计存在潜在问题：

• 两个服务使用不同的用户身份运行
• 两个服务对共享目录的权限需求不同
• 一个服务可能修改目录权限导致另一个服务无法访问

3. Redis持久化机制

Redis默认配置会定期将内存中的数据快照保存到磁盘(RDB持久化)。当无法完成这个操作时，如果配置了stop-writes-on-bgsave-error选项(默认启用)，Redis会进入保护模式拒绝写入操作。

解决方案

根据仓库所有者的最新回复，从DaWarIch 0.27.0版本开始，项目已经不再使用Redis作为依赖。因此，升级到最新版本是最直接的解决方案。

对于仍在使用旧版本的用户，可以采取以下临时解决方案：

1. 分离数据卷：为Redis和PostgreSQL分别使用独立的绑定挂载目录
2. 调整目录权限：确保Redis容器用户对数据目录有写入权限
3. 禁用持久化：在测试环境中可以临时关闭Redis持久化(不推荐生产环境)

最佳实践建议

1. 对于生产环境部署，建议使用Docker卷(volumes)而非绑定挂载(bind mounts)，因为卷由Docker管理，可以避免许多权限问题
2. 不同服务的数据存储应该隔离，避免共享存储目录
3. 定期备份重要数据时，应该明确知道哪些目录需要备份，而不是简单备份所有挂载点

总结

这个案例展示了在容器化部署中常见的文件系统权限问题，特别是在多个服务共享存储时。DaWarIch项目的最新版本已经移除了Redis依赖，从根本上解决了这个问题。对于仍在维护旧版本系统的用户，理解容器文件系统权限机制和合理规划数据存储策略是避免类似问题的关键。