挂载 MongoDB 容器时必须仅挂载 /data/db 目录，GridFS 数据仍存于其中；宿主机目录需 chown 999:999 确保权限；命名卷更安全但升级需导出/导入数据；大文件场景须限制 --wiredTigerCacheSizeGB 并调小 --syncdelay。
挂载 MongoDB 容器的 GridFS 数据目录必须避开 /data/db 本身
GridFS 不是独立存储引擎，而是 MongoDB 驱动层对大文件的分块封装机制，它底层仍写入普通集合（fs.files 和 fs.chunks），所有数据最终落在 /data/db 下。所以不存在单独“GridFS 存储卷”这个概念——你挂载的只能是整个 MongoDB 的数据目录。
常见错误是试图额外挂载一个路径给 GridFS 用，比如 -v /host/gridfs:/gridfs，这完全无效：MongoDB 不会识别或使用该路径，文件仍写进 /data/db，而挂载点没生效等于白配。
- 真正要持久化的只有
/data/db，这是 WiredTiger 引擎唯一认可的数据根目录 - GridFS 文件和普通文档一样受同一套 WAL、checkpoint、journal 机制保护
- 如果你的应用通过 GridFS 写入了 10GB 视频，这些数据就实实在在存于
/data/db下的.wt文件中，不是临时缓存
docker run 挂载 /data/db 时必须确保宿主机目录可写且权限匹配
MongoDB 容器默认以 UID 999（非 root）运行 mongod 进程，若宿主机挂载目录属主不是 999 或无写权限，容器启动直接失败，日志里出现类似 Permission denied 或 Failed to create directory /data/db。
正确做法不是改容器用户，而是提前准备目录：
- 执行
mkdir -p /mnt/mongo-data && chown 999:999 /mnt/mongo-data - 再运行
docker run -v /mnt/mongo-data:/data/db -p 27017:27017 mongo:6.0 - 若用 Docker Compose，
volumes下的路径也需提前chown，不能依赖initContainer或 entrypoint 修复（太晚，mongod 已启动失败）
使用命名卷（named volume）比绑定挂载（bind mount）更安全，但需注意初始化时机
命名卷由 Docker 管理，自动处理权限和生命周期，推荐用于生产。但它的初始化发生在容器首次启动时——如果镜像自带初始化脚本（如官方 mongo:6 镜像），它会在空卷上自动创建数据文件；但如果卷已有旧数据，Docker 不会覆盖或校验兼容性。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
风险点在于版本升级：从 MongoDB 5.x 卷直接启动 6.x 容器，可能因存储格式变更导致启动失败或数据损坏。
- 升级前先用旧版本容器导出数据：
mongodump --host localhost:27017 --out /backup - 新建命名卷：
docker volume create mongo-data-v6 - 用新版本容器挂载该卷启动，再导入：
mongorestore --host localhost:27017 /backup - 不要复用未清理的旧命名卷直接跑新版 mongod
GridFS 大文件场景下，必须同步配置容器内存与 WiredTiger 缓存
GridFS 读写大文件（如 >100MB）时，WiredTiger 默认 50% 内存缓存策略容易吃满容器内存，触发 OOM Kill。这不是挂载问题，但和持久化稳定性强相关——进程被杀，未刷盘的 journal 就可能丢失。
解决方式是在启动时显式限制缓存大小：
- 加参数：
--wiredTigerCacheSizeGB 2（假设容器内存 4GB） - Docker Compose 中写成：
command: ["--wiredTigerCacheSizeGB", "2"] - 同时建议加
--syncdelay 2缩短 journal 刷盘间隔（默认 60 秒），降低断电丢数据风险
挂载目录再稳，如果 mongod 因 OOM 被杀，最后一次 journal 之前的操作照样回滚——这点常被忽略。
