宿主机挂载目录必须预先设为容器内 mongodb 进程 uid（如 999）所属，否则因权限不足导致容器静默失败；需 chown -r 999:999 并验证 ls -ld 输出，避免依赖容器自动修复或 root 启动。
挂载目录的宿主机权限必须由容器内 MongoDB 进程 UID 控制
MongoDB 官方镜像默认以 UID 999（非 root）运行 mongod，但宿主机目录若属 root 或其他用户，容器启动时会因权限不足拒绝写入，甚至静默失败。常见现象是容器反复重启、dbpath 下无文件、日志里出现 Permission denied 但没明确提示路径。
- 先查镜像实际 UID：
docker run --rm mongo:6.0 id -u mongodb（不同版本可能用mongo或1001，别硬记） - 宿主机挂载点必须 chown 成对应 UID：
sudo chown -R 999:999 /path/to/mongo-data - 别用
docker run -u root绕过——这会让数据文件属 root，后续非 root 容器无法读，反而更难维护
避免用 bind mount 覆盖容器内 /data/db 的默认权限设置
官方镜像在 entrypoint 里会尝试 chown -R mongodb:mongodb /data/db，但 bind mount 后该目录实际归属宿主机，chown 失败且不报错。结果是容器以为权限 OK，实际写入时触发内核级拒绝。
- 不要依赖容器自动修复权限，宿主机目录权限必须预先设好
- 验证方式：启动前在宿主机执行
ls -ld /path/to/mongo-data，确保输出中 UID 和 GID 都是999 - 如果用 Docker Compose，
volumes下不能只写./data:/data/db，得配合user: "999:999"（但不如宿主机提前 chown 可靠）
敏感数据不依赖文件系统权限做唯一防护
UID/GID 限制只防宿主机上其他普通用户，对 root 用户无效。如果宿主机本身不可信（比如多租户服务器），光靠 chown 不够。
- 真正隔离需结合 Linux capabilities：启动容器时加
--cap-drop=ALL --cap-add=chown --cap-add=fowner，限制容器改权限能力 - 更彻底的做法是用 named volume +
driver_opts指定 uid/gid（如 local driver 支持o=uid=999,gid=999），但需 Docker 20.10+ - 生产环境别把
/data/db直接挂到 NFS 或 rootfs 上——NFSv3 常忽略 UID 映射，rootfs 则可能被其他容器逃逸访问
SELinux 或 AppArmor 启用时额外加标签
在 CentOS/RHEL 或启用了安全模块的系统上，即使 UID 正确，container_t 类型也可能被阻止写入宿主机目录，报错类似 avc: denied { write } for ... scontext=system_u:system_r:container_t。
- 临时调试可加
:z或:Z标签：-v /path/to/data:/data/db:z（:z多容器共享，:Z独占） - 长期方案是用
semanage fcontext为挂载路径打永久标签，再restorecon，否则每次 reboot 后失效 - AppArmor 用户需确认 profile 允许
/path/to/data/** rwk,，默认 docker-default profile 不包含自定义路径
最常被跳过的一步是验证宿主机目录的 getfacl 输出里没有 unexpected 的 ACL 条目——它们会覆盖 UID/GID 判断，导致权限看似正确实则失效。
