MongoDB切换为非root用户后全新环境初始化失败求助

针对你遇到的全新环境下MongoDB以非root用户启动后root用户丢失的问题，以下是具体排查方向和解决方法：

1. 数据目录权限不匹配 #

MongoDB默认数据目录为/data/db，如果你的Dockerfile仅配置了/home/mongodb的权限，但未处理默认数据目录，会导致初始化的用户数据无法被mongodb用户读取，重启后相当于重新初始化数据库，自然找不到root用户。

• 检查点：
  • 查看Pod启动日志，确认实际使用的dbpath路径（默认是/data/db）
  • 进入Pod执行ls -ld /data/db，验证目录所有者是否为UID 999（mongodb用户）
• 解决方法：
  在Dockerfile中添加：

  RUN mkdir -p /data/db && chown -R mongodb:mongodb /data/db
  

  或者在启动命令中指定自定义数据目录：

  docker-entrypoint.sh mongod --dbpath /home/mongodb --keyFile /replica.key --replSet rs0 --oplogSize 991 --wiredTigerCacheSizeGB ${WIRE_TIGER_CACHE_SIZE_GB:-5}
  

2. 初始化脚本的权限遗留问题 #

官方docker-entrypoint.sh在首次启动时会执行root用户初始化逻辑，但如果初始化完成后数据目录的文件权限仍为root，mongodb用户重启后无法读取这些数据。

• 检查点：
  查看初始化阶段日志后，执行ls -l /data/db/admin.*，确认用户数据文件的所有者是否为mongodb用户
• 解决方法：
  修改entrypoint脚本，在初始化完成后添加权限修正步骤：

  # 在初始化脚本末尾添加
  chown -R mongodb:mongodb /data/db
  

3. 副本集初始化与Pod重启的时序冲突 #

你指定了--replSet rs0参数，首次启动时MongoDB需要完成副本集初始化，但如果Kubernetes的探针（liveness/readiness）设置的延迟时间过短，会导致Pod在副本集和用户数据完全持久化前就重启，造成用户数据丢失。

• 检查点：
  查看日志中是否有Successfully initialized repl set的提示，确认副本集是否初始化完成
• 解决方法：
  调整Kubernetes探针的initialDelaySeconds参数，延长等待时间（比如设置为60秒），给足初始化和数据持久化时间。

4. 副本集密钥文件权限错误 #

replica.key的权限必须严格为600，且所有者为mongodb用户，否则MongoDB启动时无法读取密钥，会进入异常状态，表现为用户不存在的错误。

• 检查点：
  进入Pod执行ls -l /replica.key，确认权限为-rw-------且所有者是mongodb用户
• 解决方法：
  在挂载密钥文件后执行权限修正：

  chmod 600 /replica.key && chown mongodb:mongodb /replica.key
  

5. 初始化环境变量丢失 #

如果依赖MONGO_INITDB_ROOT_USERNAME、MONGO_INITDB_ROOT_PASSWORD等环境变量创建root用户，需确认这些变量在Pod重启后是否仍存在（官方entrypoint仅在数据目录为空时执行初始化，重启后不会重新创建用户）。

• 检查点：
  查看Pod的环境变量配置，确认初始化相关变量是否正确设置

验证步骤 #

1. 启动临时Pod挂载相同存储卷，以mongodb用户登录，检查数据目录下是否存在用户数据文件
2. 手动启动MongoDB：mongod --dbpath /data/db，连接后执行use admin; db.getUsers();，确认root用户是否存在
3. 如果用户存在但重启后丢失，重点排查启动参数和权限问题；如果用户不存在，排查初始化脚本的执行逻辑和权限

内容的提问来源于stack exchange，提问作者Dan Rozinsky