Docker Compose挂载NFS卷后Node.js应用日志未持久化问题咨询

1. 验证卷挂载配置正确性 #

首先执行docker inspect bot-app查看容器挂载信息，定位到Mounts字段：

• 确认Destination路径为/bot/logs
• 确认Source路径确实为/mnt/chatbot-efs/logs，而非docker默认的卷存储路径（/var/lib/docker/volumes/xxx/_data）
  如果Source路径异常，检查docker-compose.yml中volumes顶层配置下logs卷的driver、driver_opts配置是否与mongo_data完全对齐，排查路径拼写、参数遗漏问题。

2. 排查挂载顺序冲突 #

如果存在先启动容器、后挂载NFS到宿主机/mnt/chatbot-efs的操作，会触发该问题：docker启动容器时挂载的是宿主机未挂载NFS时的本地空目录，后续宿主机挂载NFS后会覆盖本地路径，但容器的挂载点不会同步更新，此时日志全部写入宿主机本地被覆盖的/mnt/chatbot-efs/logs目录，无法在NFS路径下查看。
修复步骤：

• 停止所有相关容器
• 卸载宿主机NFS挂载：umount /mnt/chatbot-efs
• 重新挂载NFS到对应路径
• 重新启动容器

3. 检查用户权限匹配问题 #

容器内Node进程的运行用户UID/GID与NFS目录权限不匹配时，写入会直接落到容器可写层而非NFS卷，MongoDB运行正常是因为其默认用户的UID/GID刚好匹配NFS目录权限。
排查步骤：

• 执行docker exec bot-app id查看容器内运行Node进程的UID、GID
• 执行ls -ld /mnt/chatbot-efs/logs查看宿主机NFS目录的所有者UID、GID及权限配置
  修复方式：
• 在docker-compose的bot-app服务配置中添加user: "UID:GID"参数，指定进程运行用户与NFS目录所有者一致
• 或调整NFS服务端exports配置、NFS目录权限，开放对应用户的读写权限

4. 验证路径挂载有效性 #

执行docker exec bot-app mount | grep /bot/logs，确认该路径存在对应NFS挂载记录，排查是否有其他挂载配置重叠覆盖了/bot/logs路径。

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