Container docker-db_postgres-1 Skipped: optional dependency “db_postgres” failed to start

问题场景

用户使用 Dify 1.10.1 进行 Docker Compose 自托管部署，执行 docker compose up 或类似启动命令后，PostgreSQL 容器被标记为 Skipped 并输出 optional dependency 报错，导致 Dify 服务无法正常启动。该问题在 Ubuntu 和 CentOS 9 两个操作系统上均被复现。

报错原文

Container docker-db_postgres-1     Skipped: optional dependency "db_postgres" failed to start

原因分析

可能原因包括：

• PostgreSQL 数据目录的 bind mount 路径（./volumes/db/data）在宿主机上存在权限问题，容器进程无法写入，导致启动失败并触发 optional dependency 跳过机制。
• 不同 Linux 发行版对目录权限和 SELinux 策略的处理不同，bind mount 更易受宿主目录权限、SELinux 上下文等因素影响，从而造成跨系统的一致性问题。
• 当前官方 compose 配置在顶层 volumes 段没有 postgres-data 声明，与 PostgreSQL 服务引用的挂载方式不匹配（二者指向同一数据路径但方式不一致），可能引发配置歧义。

环境排查

• 确认宿主机上 ./volumes/db/data 目录是否存在，以及其属主和权限是否为当前运行 Docker 的用户可写（例如 ls -ld ./volumes/db/data）。
• 检查 docker compose config 输出的 PostgreSQL 服务 volumes 部分，确认实际生效的挂载方式。
• 确认 Docker 版本及 Compose 插件版本是否满足 Dify 1.10.1 的要求。
• 在 CentOS 9 等使用 SELinux 的系统上，检查 SELinux 是否拦截了 bind mount 的访问（可通过 ausearch 或临时 setenforce 0 排查，但生产环境不建议长期关闭）。
• 查看 PostgreSQL 容器日志以定位具体失败原因：docker logs docker-db_postgres-1。

解决步骤

1. 先备份当前的 docker/docker-compose.yaml 文件，便于回滚。
2. 编辑 docker/docker-compose.yaml，定位 PostgreSQL 服务的数据卷挂载行（约 788 行附近），将 bind mount 改为命名卷：

   volumes:
     - postgres-data:/var/lib/postgresql/data

3. 在文件末尾的顶层 volumes 段（约 1509 行附近）新增 postgres-data: 声明，与 oradata、dify_es01_data 并列。
4. 执行 docker compose down -v 清理旧容器和旧数据卷（注意：-v 会删除匿名卷和命名卷，postgres-data 为新增命名卷不在其中，但 ./volumes/db/data 宿主机目录不会被删除）。
5. 重新执行 docker compose up -d 启动全部服务。
6. 若问题依旧，可尝试将 ./volumes/db/data 目录权限调整为当前 Docker 运行用户可写，或检查 SELinux 上下文，但这是未经验证的补充手段。

验证方法

执行 docker compose ps 检查 PostgreSQL 容器是否处于 Up 状态且不再出现 Skipped；同时执行 docker logs docker-db_postgres-1 查看 PostgreSQL 是否完成初始化并进入监听状态。

参考来源

langgenius/dify #29040

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。