必须显式设置 size 参数（如 size=128m），否则 tmpfs 可占用主机内存达 50%，引发 oom；安全需组合 noexec,nosuid,nodev；推荐用 --mount 替代 --tmpfs 以增强可控性与调试能力。
直接上干货：docker tmpfs 挂载不是“加个 --tmpfs 就完事”，关键在参数组合、内存边界控制和安全策略闭环。用错会引发内存泄漏、容器启动失败、敏感数据意外落盘，甚至被利用执行提权攻击。
必须显式设置 size，否则等于裸奔
默认不设 size 时，tmpfs 可占用主机内存上限达物理内存的 50%（Linux 内核行为），且无预警膨胀。一个日志狂写的容器可能瞬间吃光宿主机内存，触发 OOM Killer 杀掉关键进程。
- 始终用 size=xxx 明确限制，单位支持 k/m/g（如
size=128m、size=2g） - 预估峰值用量 × 1.5 做余量，例如缓存目录实测最大占 40MB，建议设
size=64m - 避免写
size=0或空值——Docker 会忽略该参数，退化为无限制模式
安全参数三件套：noexec,nosuid,nodev 缺一不可
仅挂载 tmpfs 不代表安全。若未禁用执行权限，攻击者可通过写入恶意二进制并执行实现容器逃逸；若未关闭 suid/nodev，可能构造特权提权路径。
- noexec：禁止任何可执行文件运行，阻断 shell 注入后执行 payload
- nosuid：忽略 setuid/setgid 位，防止普通用户冒充 root 运行程序
- nodev：禁止创建设备文件（如 /dev/zero、/dev/sda），杜绝绕过文件系统限制的设备访问
- 推荐组合：
rw,noexec,nosuid,nodev,size=64m
用 --mount 替代 --tmpfs，获得更清晰的语义与调试能力
--tmpfs 是快捷语法，但隐藏了底层挂载细节，出问题时难以定位；--mount 更显式、可读性强，且支持完整 tmpfs 选项集（包括 tmpfs-mode、tmpfs-uid 等），是生产环境首选。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 等效写法对比：
- 旧方式：
--tmpfs /tmp:rw,noexec,nosuid,size=64m - 新方式：
--mount type=tmpfs,destination=/tmp,tmpfs-size=67108864,tmpfs-mode=1777（注意：size 单位是字节） - 优势：可单独指定 uid/gid（
tmpfs-uid=1001,tmpfs-gid=1001），适配非 root 应用；mode 支持八进制（如1777保证 sticky bit）
排错四步定位法：从容器启动失败到数据残留
遇到 tmpfs 相关异常，按顺序检查以下四点，90% 问题可快速定位：
-
启动报错 “invalid argument” 或 “operation not permitted” → 检查是否在容器内以非 root 用户运行，且未用
tmpfs-uid/tmpfs-gid匹配；或宿主机启用了严格的安全模块（如 SELinux/AppArmor），需添加对应策略 - 容器内能写入但应用读不到文件 → 确认挂载路径与应用配置路径完全一致（区分大小写、尾部斜杠）；检查是否被上层 volume/bind mount 覆盖（Docker 挂载顺序：bind mount > volume > tmpfs）
-
容器停止后 /tmp 下仍有文件 → 不是 tmpfs！说明挂载失败，实际使用的是容器可写层或匿名卷。用
docker exec -it <container> findmnt | grep tmpfs</container>验证是否真实挂载 -
宿主机内存持续上涨不释放 → tmpfs 数据未被及时回收。检查是否因应用未 close 文件描述符导致 inode 泄漏；或内核未触发 shrinker 回收，可临时调大
/proc/sys/vm/vfs_cache_pressure加速清理
真正可靠的 tmpfs 配置，是 size 有界、权限受限、挂载可验、行为可控。别把它当“高级缓存开关”，而要当作运行时安全隔离面来设计。
