【Bug 报告】面板权限整理逻辑将 Compose 数据卷子目录 chmod ...
【Bug 报告】面板权限整理逻辑将 Compose 数据卷子目录 chmod 为 0600（丢失 x 位），导致 PostgreSQL 容器 Permission denied 死循环项目值
宝塔面板版本v11.8.1
操作系统Ubuntu 24.04.4 LTS
架构x86_64
内核6.8.0-134-generic
Docker29.6.1
docker-compose5.3.0
部署方式面板「Docker 管理 / Compose」管理器，数据卷默认相对路径
文本编辑
1could not open file "global/pg_control": Permission denied2could not open directory "base/...": Permission denied
文本编辑
1drwx------70 70. ← 顶层正常（被 postgres entrypoint 的 chmod 700 救回）2drw-------70 70global ← 子目录缺 x（被面板逻辑改坏）3drw-------70 70base4drw-------70 70base/163845drw-------70 70pg_commit_ts6drw-------70 70pg_dynshmem7-rw-------70 70global/pg_control← 文件本身正常8-rw-------70 70PG_VERSION
[*]属主（UID 70）全程未被改坏，问题不是属主错误，而是目录 mode 缺 x。
[*]POSIX 语义：目录无 x 位 → 即使是属主也无法进入该目录、无法 open 其中文件 → EACCES。
[*]官方 postgres entrypoint 启动时仅执行 chmod 700 $PGDATA（只修顶层），不递归修复子目录，因此无法自愈，形成死循环。
[*]/tmp/last_files_set_mode.pl 标记文件的 mtime 与容器首次报错时刻吻合。
[*]保存面板设置
[*]开关面板 SSL / API 接口
[*]绑定宝塔 APP
[*]计划任务中的权限修复/加固类任务到点执行
[*]所有通过面板 Compose 管理器部署、数据卷落在 /www/server/panel/data/compose/ 下、且容器内进程对目录可进入性敏感的应用（PostgreSQL 为典型）。
[*]数据内容未损坏，但服务完全不可用，且表现为"重启无效"的死循环，易被误判为数据损坏。
此致，宝塔面板研发团队
页:
[1]