Docker 共享卷的权限怎么管才不踩坑？

问题本质：容器内进程的 UID/GID 与宿主机上卷目录的属主经常对不上——是否允许写入由数字 UID/GID、模式位、ACL、安全策略和挂载选项共同决定，属主不同不必然被拒绝。最佳实践四件套：明确容器运行 UID → 宿主机目录预先 chown 成该 UID → 应用数据优先用命名卷（空卷可能复制镜像路径内容，仍需核对权限）→ 永远别图省事 chmod 777。

诊断：先搞清两边是谁

# exec 会话身份不一定等于应用实际身份，应用可能在启动后降权
docker exec myapp id

# 宿主机卷目录属主
ls -ln /opt/app/data

两个数字对上了，权限问题就解决了大半。

方案一：宿主机预对齐（bind mount）

sudo mkdir -p /opt/app/data
sudo chown 1000:1000 /opt/app/data    # 仅对确认归属的专用目录；现有文件逐项评估
docker run -d -v /opt/app/data:/data -u 1000:1000 myimage

方案二：命名卷（省心首选）

docker run -d -v appdata:/data myimage

空卷挂到镜像中已有内容的路径时通常会复制初始化内容，除非配置 nocopy；已有卷不会重新按镜像修正属主，因此仍需核对实际权限。

方案三：entrypoint 动态修正

镜像入口脚本里（root 启动时）：

#!/bin/sh
# 仅在确认 /data 是本应用专用目录且需要时修改，避免盲目递归修改共享数据
chown appuser:appuser /data
exec su-exec appuser "$@"    # 降权运行主进程

官方 postgres/mysql 镜像都是这个模式。

多容器共享卷

多个容器挂同一卷时，统一各容器的运行 UID/GID（镜像里统一创建同 ID 用户），或共用一个组：确认专用目录后用 chgrp 3000 /opt/app/data 与 chmod g=rwX /opt/app/data，已有文件逐项评估，各容器 --group-add 3000；新建文件的组继承还需目录 setgid，写权限还需合适的 umask 或默认 ACL。

反面教材

• chmod -R 777：能通但把门全开了，生产环境禁
• 容器内一律 root 跑：回避了权限问题，引入了安全问题
• SELinux 系统忘记 :z/:Z：现象同样是 permission denied，加后缀重新打标

常见问题（FAQ）

Q：怎么知道镜像里应用用户的 UID？
A：docker run --rm --entrypoint id myimage 只能查看镜像配置的默认用户；应用若由入口脚本降权，还需检查该脚本及实际应用进程的 UID。

Q：rootless Docker 下权限模型有什么不同？
A：容器内 root 映射到宿主机普通用户，其他容器 UID/GID 还可能映射到 subordinate IDs，bind mount 仍可能冲突，应按实际映射检查。

Q：K8s 里怎么处理？
A：Pod 安全上下文里配 fsGroup，支持的卷插件可能调整组属主，CSI 驱动也可能自行处理；并非所有卷类型都支持或有相同行为，应配合 runAsUser 和驱动文档验证。