docker中加:ro只需在-v参数末尾添加，如-v /host:/container:ro，仅限制该挂载点为只读；常见错误包括路径写错、挂载未生效（windows需开启file sharing）或被其他挂载（如tmpfs）覆盖，应通过docker inspect确认mounts中rw为false。
docker run 里怎么加 :ro 挂载选项
直接在 -v 参数末尾加 :ro 即可，这是最常用、最轻量的只读挂载方式。它只影响该挂载点，不影响容器其他路径。
常见错误现象：加了 :ro 还能写入？那大概率是挂载路径写错了，或者容器内进程实际写的是另一个未挂载的路径（比如误写成 /config，但挂载的是 /etc/config）。
-
docker run -v C:/myconf:/app/conf:ro nginx—— Windows 下绑定挂载配置目录为只读 -
docker run -v mydata:/app/data:ro mysql—— 命名卷只读挂载，防止数据库容器意外覆盖数据卷 - 不能混用：
-v /host:/container:ro:z是非法语法，:ro和:z不能同时出现在一个挂载项中
docker-compose.yml 中 read_only: true 是什么层级的控制
read_only: true 是服务级配置，会让整个容器根文件系统（/）变成只读——包括镜像层里的所有路径。这比 :ro 严格得多，也危险得多。
不配 tmpfs 就启动失败是常态，因为 /tmp、/run、/var/run 这些路径默认不可写。nginx、supervisord、甚至 shell 的 cd 都可能报错。
- 必须显式声明 tmpfs：在
services下加tmpfs: ["/tmp", "/run", "/var/run"] - 不能只写
read_only: true就完事，否则容器卡在启动阶段，日志里出现Permission denied或直接退出 - 该配置和卷挂载的
:ro无关——即使某个卷挂载用了:rw，read_only: true仍会锁死整个根文件系统
Windows 上挂载失败却没报错？先查 File Sharing 设置
Docker Desktop 在 Windows 上不会主动提示“你没开共享”，而是静默失败或挂载为空目录。这不是权限问题，是根本没授权访问磁盘。
跳过这步，:ro 或 read_only: true 都白搭，因为挂载压根没生效。
- 右键任务栏 Docker 图标 → Settings → Resources → File Sharing
- 勾选对应盘符（如
C:或E:），确认右侧无红色警告图标 - 点
Apply & Restart，等状态栏显示Docker Desktop running - 验证方法：进容器执行
ls /mnt（假设挂载到/mnt），如果返回空，八成是这步漏了
为什么改了配置重启容器还是能写？检查挂载是否被覆盖
容器内路径如果被多次挂载（比如既有 volumes 又有 tmpfs，或多个 -v 指向同一目标），后写的会覆盖前写的，只读设置可能被悄悄绕过。
尤其在 compose 文件里，volumes 和 tmpfs 同时存在且目标路径重叠时，行为取决于 Docker 版本，但通常 tmpfs 会覆盖原有挂载，导致 :ro 失效。
- 用
docker inspect 容器名查看Mounts字段，确认RW值为false，且挂载源路径正确 - 避免路径冲突：不要让
volumes: ["./conf:/app/conf:ro"]和tmpfs: ["/app/conf"]同时存在 - 命名卷只读挂载后，宿主机上对应目录（
/var/lib/docker/volumes/xxx/_data）仍可被其他进程写入，:ro仅限制容器视角
