MongoDB 5.0+强制要求keyfile权限必须为400（-r--------），因校验逻辑仅接受所有者可读、不可写不可执行；chmod 600含写位（w）会被直接拒绝，且属主、父目录x权限、SELinux上下文等也须同步合规。
因为 MongoDB 5.0+ 强制要求 keyfile 权限必须是 400（即 -r--------），chmod 600 或其他权限都会被拒绝，且错误日志里“permissions are too open”不是提示你放宽限制，而是告诉你——还不够严。
为什么 chmod 600 会触发 permissions error
MongoDB 自 5.0 起把 keyfile 安全模型收紧为“仅所有者可读、不可写、不可执行”，600 含有写位（w），哪怕属主是正确用户，也会被校验逻辑直接拦截。这不是 Linux 权限机制的问题，是 MongoDB 进程自己做的硬检查。
-
chmod 600 /etc/mongod-keyfile→ 启动失败，日志仍报permissions on /etc/mongod-keyfile are too open -
chmod 400 /etc/mongod-keyfile→ 才可能通过第一关校验（前提是属主和路径也对） - 别试
440、644、700，全会被拒；400是唯一被接受的数值
chown 和 chmod 的顺序不能错
某些系统（尤其是 RHEL/CentOS）下，chown 会重置文件权限位。如果你先 chown mongodb:mongodb /etc/mongod-keyfile 再 chmod 400，chown 可能悄悄把权限改回 600，导致后续启动失败。
- 正确顺序：
chmod 400 /etc/mongod-keyfile && chown mongodb:mongodb /etc/mongod-keyfile - 验证命令：
ls -l /etc/mongod-keyfile输出必须是-r-------- 1 mongodb mongodb - 属主必须是
mongod进程实际运行用户（用ps -u mongodb -o comm=或ps aux | grep mongod确认，常见为mongodb或mongod）
权限对了还报 Permission denied？查父目录和 SELinux
ls -l 显示 400 且属主正确，但 sudo -u mongodb cat /etc/mongod-keyfile 仍报 Permission denied，说明问题不在 keyfile 本身，而在访问链路上。
- 父目录（如
/etc）必须对mongodb用户有执行权（x位），否则进不去目录：运行sudo -u mongodb ls -ld /etc，确保输出含dr-xr-xr-x或类似（所有者有x） - SELinux 启用时，
ls -Z /etc/mongod-keyfile若显示上下文类型不对（如user_home_t），需修复：sudo semanage fcontext -a -t mongod_etc_t "/etc/mongod-keyfile"，再sudo restorecon -v /etc/mongod-keyfile - Ubuntu/Debian 用户检查 AppArmor：
aa-status | grep mongod，确认规则含/etc/mongod-keyfile r
Docker 中 keyfile 权限容易被覆盖
用 -v 绑定挂载时，宿主机上的文件权限和属主会直接覆盖容器内设置，Dockerfile 里的 RUN chmod 400 无效。
- 方案一（推荐）：宿主机上先执行
chmod 400 /host/path/keyfile && chown 999:999 /host/path/keyfile（999 是官方 mongo 镜像默认 UID） - 方案二：启动容器时加
--user root，进容器后手动chown 999:999 /keyfile && chmod 400 /keyfile，再切回mongod用户启服务 - 方案三：不用挂载，改用
docker cp把 keyfile 复制进运行中容器，再在容器内修正权限
真正卡住人的，往往不是 400 这个数字本身，而是改完权限后没验证 mongod 用户能否真读、父目录有没有 x、SELinux 上下文是否同步、或者配置里 security.keyFile 路径写成了相对路径或带 ~ ——这些地方出错，日志都统一报成 “permissions” 相关错误，容易反复调试却绕不开根因。
