Docker卷权限管理完全依赖Linux原生访问控制模型。容器内进程能否读写挂载文件，取决于其UID/GID是否匹配宿主机文件的属主/属组及rwx权限位；ro/rw挂载选项仅控制mount层开关，不改变底层权限；启用userns-remap可隔离UID映射，增强安全性；SELinux/AppArmor等强制访问控制机制也会叠加额外限制。
docker 卷权限管理不是 docker 自创的规则，而是完全依托 linux 原生的访问控制模型实现的。理解这一点，才能避开 80% 的“permission denied”类故障。
Linux 文件权限是基础底座
每个文件和目录在 Linux 中都有明确的所有者（UID）、所属组（GID）以及三组 rwx 权限位（所有者、组、其他）。Docker 挂载卷时，不会改写这些元数据，只是把宿主机路径以 bind mount 方式映射进容器命名空间。这意味着：
- 容器内进程能否读写某个挂载文件，首先取决于该进程运行时的 UID/GID 是否匹配文件的 owner/group 权限
- 即使挂载选项设为 rw，若容器内进程 UID 是 1001，而宿主机上目标文件属主是 UID 2000 且权限为 -rwx------，依然无法访问
- chmod/chown 在容器内执行，修改的是宿主机上对应文件的权限和属主（除非启用 user namespace 隔离）
挂载选项（ro/rw/默认）只是 mount 层的开关
Docker 的 -v /host:/cont:ro 实际调用的是 Linux mount -o remount,ro,bind。它不改变文件本身的 UID/GID 或权限位，只叠加一层运行时限制：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- ro：禁止任何写入系统调用（open(O_WRONLY|O_RDWR)、write、truncate 等直接失败）
- rw：解除该限制，但是否真能写，仍由底层文件权限和进程 UID 决定
- 无显式选项（默认）：等价于 rw，但部分旧版内核或 SELinux 启用时可能隐含 noexec,nosuid 等安全 flag
用户命名空间（UserNS）是权限隔离的关键变量
当启用 --userns-remap 或 userns-remap=default 时，Docker 会将容器内 UID 映射到宿主机上一段隔离的 UID 范围（如容器内 UID 0 → 宿主机 UID 165536）。这带来两个直接影响：
- 容器内 root 创建的文件，在宿主机上显示为非特权 UID 所有，普通用户无法误删或覆盖
- 宿主机上原属 UID 0 的目录，若未在映射范围内开放，容器内进程即使以 root 运行也无法访问
- 未启用 UserNS 时，“容器 root = 宿主机 root”，权限失控风险极高
SELinux/AppArmor 是绕不开的增强层
在启用 SELinux 的发行版（如 RHEL/CentOS/Fedora）中，Docker 默认为容器进程打上 system_u:system_r:container_t:s0 标签，并对挂载路径施加类型强制（type enforcement）：
- 宿主机目录若未打上 container_file_t 或 svirt_sandbox_file_t 标签，即使权限全开，容器也会被 SELinux 拒绝访问
- 可用
ls -Z /host/path查看上下文，用chcon -t container_file_t /host/path临时修复 - AppArmor 在 Ubuntu 上作用类似，需确认容器 profile 是否允许对目标路径的 read/write/mount 访问
