MongoDB容器启动失败因keyfile权限或属主不符：必须为400/600且属主UID 999，Docker bind mount忽略宿主机属主，需在容器内用entrypoint或user: root修正，同时校验路径、SELinux上下文及配置一致性。
Keyfile必须以400或600权限挂载，且属主必须是MongoDB容器内运行用户（UID 999），否则启动直接失败——不是报错“权限不足”，而是静默退出或卡在bad file。
为什么chmod 644或600在宿主机上设对了也不行？
因为Docker默认挂载时会忽略宿主机的属主信息，容器内看到的文件属主仍是root，而官方mongo镜像固定以UID 999（用户名mongodb）运行。即使ls -l在宿主机显示-rw------- 1 mongodb mongodb，进容器一查就是-rw------- 1 root root。
- 用
docker exec -it mongo1 ls -l /data/configdb/mongo.keyfile确认容器内真实属主 - 不要依赖宿主机
chown，它对bind mount无效 - 常见误操作：Ansible用
copy模块传keyfile，默认权限是644，且不会自动chown到999
三种安全挂载方式怎么选？
核心原则：让容器内/data/configdb/mongo.keyfile的权限为400或600，属主为UID 999。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
-
推荐用
entrypoint脚本修正：在docker-compose.yml中加entrypoint，先chmod 400 /data/configdb/mongo.keyfile && chown 999:999 /data/configdb/mongo.keyfile，再exec docker-entrypoint.sh "$@" -
用
user: root临时提权：在service里设user: root，命令里显式chown 999:999 && chmod 400，但需注意mongod最终仍要降权运行（官方镜像会自动处理） -
避免用
volume挂载整个configdb目录：容易混入其他配置文件，导致权限策略被绕过；应只挂载keyfile单个文件
keyFile路径写错会提示“Permission denied”？
会。MongoDB不区分“文件不存在”和“权限拒绝”，只要open()系统调用失败，一律报Permission denied。比如keyFile: /data/key/mongo.keyfile但实际挂载到/data/configdb/，或路径多一个/（如/data/configdb//mongo.keyfile），都会触发这个误导性错误。
- 检查
mongod.conf里的security.keyFile值是否与docker run -v或volumes中映射的目标路径完全一致 - 进容器执行
ls -l $(cat /etc/mongod.conf | grep keyFile | awk '{print $2}')，确认文件真实存在且可读 - SELinux启用时，还要
ls -Z /data/configdb/mongo.keyfile，上下文类型应为mongod_etc_t，否则chcon -t mongod_etc_t /path/to/keyfile
真正难调试的从来不是“怎么设权限”，而是“谁在哪个环节改了属主、谁覆盖了权限、谁拼错了路径”。每次改完务必进容器验证三件事：ls -l看权限和属主、cat试读、sudo -u mongodb mongod --config /etc/mongod.conf --nojournal --port 27018 --bind_ip 127.0.0.1手动跑一次校验。
