结论：chmod 600 不行，必须用 chmod 400；MongoDB 5.0+ 强制要求 keyfile 权限为 400（仅所有者可读），因写权限（w）被视为不安全，600 仍会报“permissions are too open”并启动失败。
直接说结论：chmod 600 不行，必须用 chmod 400。 MongoDB 5.0+ 启动时若报 permissions on /path/to/keyfile are too open，改 600 是常见误区——它仍会被拒绝，不是权限不够严，而是“太开”的判定逻辑变了。
为什么 chmod 600 会失败
MongoDB 从 4.2 开始收紧校验逻辑，5.0 起彻底执行“仅所有者可读”硬规则：600 允许所有者读写，但写权限（w）本身就被视为不安全；只有 400（-r--------）满足“不可修改、仅可读”要求。这不是 Linux 权限常识能推导出的，是 MongoDB 自己定的策略。
-
chmod 600 /etc/mongod-keyfile→ 启动报错，日志里还是permissions are too open -
chmod 400 /etc/mongod-keyfile→ 才可能通过校验（前提属主正确、路径可达） - 别试
644、700或440，全都会被拒
改权限前必须确认的三件事
只跑 chmod 很大概率白忙——真正卡住的是组合条件。
- 文件属主必须是运行
mongod的用户（通常是mongod或mongodb），不是root：用ps -u mongod -o comm=确认进程用户，再chown mongod:mongod /etc/mongod-keyfile - 父目录（比如
/etc或/data）得让该用户有执行权（x），否则进不去：检查ls -ld /etc，确保输出里有dr-xr-xr-x或类似（至少所有者有x） - 别放在
/tmp、/home/xxx或 NFS 挂载点上——这些位置可能绕过或不支持精确权限校验，MongoDB 会直接放弃
验证是否真能读，别信 ls -l
权限数字对了，不等于 mongod 进程真能打开它。最可靠的测试方式是模拟运行用户去读：
sudo -u mongod cat /etc/mongod-keyfile
如果报 Permission denied，说明要么属主不对、要么 SELinux/AppArmor 拦截、要么路径在受限挂载点。这时候看 journalctl -u mongod -n 50 --no-pager，错误源头通常就在最后几行，比猜权限更准。
- SELinux 用户（RHEL/CentOS/Fedora）：临时关掉测试
setenforce 0，若启动成功，就需补上下文：semanage fcontext -a -t mongod_etc_t "/etc/mongod-keyfile"+restorecon -v /etc/mongod-keyfile - AppArmor 用户（Ubuntu/Debian）：检查
aa-status | grep mongod，规则里必须含/etc/mongod-keyfile r
Docker 场景下 keyfile 权限怎么设
容器里问题更隐蔽：宿主机文件属主是 root，挂进容器后，mongod 用户（UID 999）默认读不了。
- 别用
docker run -v /host/key:/keyfile mongo直接挂——权限和属主都继承自宿主机 - 正确做法是在 Dockerfile 里做两件事：
RUN chown 999:999 /keyfile+RUN chmod 400 /keyfile - 或者用初始化脚本，在容器启动第一秒就执行
chown 999:999 /keyfile && chmod 400 /keyfile
最容易被忽略的是：Docker 默认 copy 文件时权限是 644，即使你本地 chmod 400 了，COPY 后也会重置——必须显式用 RUN chmod 回来。
