Docker Desktop容器提示Read-only file system，根本原因在于Windows路径未被Docker Desktop共享或宿主机目录/文件系统不支持写入；首要排查点是File Sharing白名单配置、OneDrive等同步目录干扰、NTFS权限及WSL2挂载参数限制。
直接给结论：Docker Desktop 容器提示 Read-only file system，**不是镜像问题，也不是 Windows 权限设置错，而是挂载路径未被 Docker Desktop 共享，或宿主机目录权限/文件系统本身不支持写入**。Windows 下的路径映射失败是首要排查点。
确认 Docker Desktop 是否已共享对应 Windows 路径
Windows 主机上的路径（如 C:\Users\Alice\project）对容器内 Linux 环境不可见，除非显式加入 Docker Desktop 的 File Sharing 白名单：
- 打开 Docker Desktop → Settings → Resources → File Sharing
- 检查目标路径是否在列表中；若没有，点击
+添加（例如C:\Users\Alice） - 添加后必须点击
Apply & Restart，否则配置不生效 - 常见错误：只加了
C:\却没重启，或路径含中文/空格导致共享失败（建议用英文路径）
检查宿主机目录是否可写且文件系统支持
Docker Desktop 只是“转发”访问请求，最终写入成败取决于 Windows 目录本身的属性和文件系统：
- 确保该目录不是只读属性：右键文件夹 → 属性 → 取消勾选“只读”
- 避免使用 NTFS 加密（EFS）或 BitLocker 加密卷，Docker WSL2 子系统可能无法解密
- 不要挂载到 OneDrive、Google Drive 或 Dropbox 同步目录——这些客户端会拦截/延迟/拒绝底层文件系统调用，极易触发
Read-only file system - 若用 WSL2 后端，
wsl -d docker-desktop df -h查看/mnt/c/...挂载选项，确认是否带noexec,nosuid,nodev,uid=0,gid=0,umask=22,fmask=11——其中fmask=11会让普通文件默认无写权限，需在挂载时显式加umask=000（但 Docker Desktop 不暴露该控制）
验证容器内用户是否有写权限
即使路径可访问，容器内进程 UID/GID 若不匹配宿主机目录属主，仍会写失败：
- 进入容器：
docker exec -it myapp sh - 运行
id查看当前 UID（如uid=1001） - 检查挂载点权限：
ls -ld /host/path，确认该 UID 在宿主机上有写权限 - 若宿主机目录属主是
Administrator，而容器用非 root 用户运行，chmod 777是最简验证手段（仅调试用） - 生产环境应改用
chown 1001:1001 /host/path（需在 Windows 启用 WSL2 的 metadata 支持，并在/etc/wsl.conf中配metadata=true）
绕过挂载限制：用 docker cp + tmpfs 替代实时写入
当共享路径始终不稳定（比如 CI 环境或临时调试），与其反复折腾挂载，不如换思路：
- 把配置文件从宿主机拷进容器：
docker cp ./config.yaml myapp:/tmp/config.yaml - 启动容器时用
--tmpfs /tmp:rw,noexec,nosuid,size=16m确保/tmp可写且隔离 - 应用启动前从
/tmp/config.yaml复制到实际路径（如/etc/app/config.yaml），前提是该路径在只读镜像里本就允许覆盖（即容器层可写） - 注意：
docker cp不支持反向修改（容器→宿主机需再cp出来），也不适用于大文件流式写入场景
Windows 下的只读报错，90% 都卡在 Docker Desktop 共享配置或 OneDrive 同步干扰上。别急着改镜像或加 --privileged，先确认路径是否真能被 WSL2 看见、能否被容器 UID 写入——这两步跳过，后面所有操作都是在掩盖根本问题。
