Docker 共享卷的权限怎么管才不踩坑？
卷权限问题源于容器内 UID 与宿主机文件属主不匹配。最佳实践：明确容器运行 UID、宿主机预先 chown 对齐、优先命名卷（Docker 自动初始化权限）、避免宽限 777。本文给出完整方案。
问题本质：容器内进程的 UID/GID 与宿主机上卷目录的属主经常对不上——容器里 UID 1000 的 app 用户写宿主机 root 属主的目录就是 permission denied。最佳实践四件套：明确容器运行 UID → 宿主机目录预先 chown 成该 UID → 应用数据优先用命名卷（首次挂载时 Docker 会按镜像内路径属主自动初始化）→ 永远别图省事 chmod 777。
诊断：先搞清两边是谁
# 容器内进程身份
docker exec myapp id
# 宿主机卷目录属主
ls -ln /opt/app/data
两个数字对上了，权限问题就解决了大半。
方案一：宿主机预对齐（bind mount）
sudo mkdir -p /opt/app/data
sudo chown -R 1000:1000 /opt/app/data # 容器内 app 用户是 UID 1000
docker run -d -v /opt/app/data:/data -u 1000:1000 myimage
方案二：命名卷（省心首选）
docker run -d -v appdata:/data myimage
命名卷首次挂载时，Docker 会把镜像中 /data 目录的内容与属主初始化进卷——镜像里配好的属主自动带出来，免去手动 chown。
方案三：entrypoint 动态修正
镜像入口脚本里（root 启动时）：
#!/bin/sh
chown -R appuser:appuser /data
exec su-exec appuser "$@" # 降权运行主进程
官方 postgres/mysql 镜像都是这个模式。
多容器共享卷
多个容器挂同一卷时，统一各容器的运行 UID/GID（镜像里统一创建同 ID 用户），或共用一个组：宿主机目录 chgrp -R 3000 + chmod -R g=rwX，各容器 --group-add 3000。
反面教材
chmod -R 777：能通但把门全开了，生产环境禁- 容器内一律 root 跑：回避了权限问题，引入了安全问题
- SELinux 系统忘记
:z/:Z：现象同样是 permission denied，加后缀重新打标
观测云对照
权限问题在日志里有特征。 应用报 permission denied 的日志被采集后，配合容器事件（启动失败、重启）可以快速定位到挂载权限问题；观测云的统一日志检索让这类跨主机问题排查标准化。
常见问题（FAQ）
Q：怎么知道镜像里应用用户的 UID？
A：docker run --rm --entrypoint id myimage，或看 Dockerfile 的 useradd/USER。
Q：rootless Docker 下权限模型有什么不同？
A：容器内 root 映射到宿主机普通用户，卷权限天然以宿主用户为基准，bind mount 冲突反而少了。
Q：K8s 里怎么处理？
A：Pod 安全上下文里配 fsGroup，K8s 会自动调整卷内文件组属主，配合 runAsUser 使用。
