mongodb 5.0+要求keyfile权限严格为400（-r--------），否则启动失败报“keyfile permissions are too open”；需chmod 400、chown正确用户、确保父目录有x权限，并检查selinux/apparmor拦截。
Keyfile权限必须是400，不是600也不是644
MongoDB 5.0起，副本集启动时若keyFile权限不是严格400（即-r--------），会直接报Keyfile permissions are too open并退出，不是警告，是致命错误。你看到的AuthenticationFailed往往只是表象——真正卡住的是mongod根本没起来，后续所有连接失败都源于此。
常见误操作包括：
-
chmod 600→ 虽然属主可读写，但MongoDB认为“too open”，拒绝加载 -
chmod 644或chmod 755→ group/other有读或执行位，必然失败 - 用
touch创建后没改权限 → 默认可能是644，直接中招
正确命令只有一条：chmod 400 /path/to/keyfile。别犹豫，别加-R，就这一行。
mongod用户必须能读keyfile，且父目录也要放行
权限设对了，ls -l也显示-r--------，但mongod还是报Failed to load keyfile: Permission denied？大概率是用户没读权，或路径中间某一级目录拦住了。
验证是否真能读：
- 先查mongod服务用户：
ps aux | grep mongod，看USER列（通常是mongod或mongodb） - 再模拟它去读：
sudo -u mongod cat /path/to/keyfile—— 如果报错，说明权限链断了 - 检查父目录：
sudo -u mongod ls -ld /path/to，确保每一级都有x（执行位，即进入权限）
特别注意：/home/xxx/、/tmp/这类路径常被SELinux或系统策略默认限制，不建议放keyFile；推荐放在/etc/或/var/lib/mongodb/下。
SELinux或AppArmor会静默拦截，即使权限全对
你在CentOS/RHEL/Fedora上改完400、chown好，重启还是失败，日志里却只说Permission denied，没提权限位——八成是SELinux在拦。
快速验证：
- 临时关闭：
sudo setenforce 0，再启mongod；如果成功，就是SELinux问题 - 永久修复：
sudo semanage fcontext -a -t mongod_etc_t "/path/to/keyfile"，然后sudo restorecon -v /path/to/keyfile - Ubuntu/Debian用户检查AppArmor：
aa-status | grep mongod，确认规则里有类似/path/to/keyfile r,这一行
别跳过这步：很多团队花半天调权限，最后发现是SELinux上下文没更新，restorecon一跑就通。
keyfile内容必须字节一致，且不能有BOM或换行
权限和SELinux都过了，节点间仍报No keys found for replica set或同步卡在STARTUP2？可能是keyfile内容不一致。
关键点：
- 所有副本集节点的
keyFile必须是**完全相同的二进制内容**，不能只是“看起来一样” - 用
sha256sum /path/to/keyfile在每台机器上比对，输出必须一字不差 - 生成时别用
echo "secret" > keyfile—— 它会加换行符；改用echo -n "secret" > keyfile，或更稳妥的openssl rand -base64 756 > keyfile - Windows编辑器保存可能带BOM，Linux下用
file keyfile确认是data类型，不是UTF-8 Unicode (with BOM) text
真正难排查的，往往是权限和SELinux都对了，但两台机器的keyfile哈希值不同——因为复制时用了scp却没关text mode，或者手敲漏了一个字符。
