Docker Compose挂载共享网络卷报错（Windows宿主机/Linux容器）

两类报错均与容器内/mnt/my_vol路径权限无关。Docker挂载CIFS类型命名卷的逻辑是：先在宿主机层面将网络共享挂载到Docker本地卷目录（即报错中出现的/var/lib/docker/volumes/cont_my_vol/_data），再将该本地目录绑定挂载到容器内指定路径，容器内路径只要是合法Linux路径就不会触发挂载故障，所有问题均出在宿主机侧的CIFS挂载环节。

报错1：no such file or directory #

该报错指向CIFS共享源连通性、路径合法性或基础组件缺失，按以下顺序排查：

• 开启Windows原生CIFS客户端支持：打开「控制面板-程序-启用或关闭Windows功能」，勾选「SMB 1.0/CIFS 文件共享支持」下的客户端子项，重启系统生效。Docker Desktop依赖Windows原生CIFS能力完成挂载，缺失该组件无法识别cifs类型卷。
• 验证共享源可访问：直接在Windows资源管理器地址栏输入\\xxx.xx.com\<MY_FOLDER>，确认可正常打开、读写文件，排除账号密码错误、共享名拼写错误、网络不通、共享目录不存在的问题。注意CIFS路径不能多写/少写目录层级，拼写需和共享配置完全一致。
• 适配WSL2后端场景：如果Docker Desktop使用WSL2后端，先进入WSL终端执行smbclient -L //xxx.xx.com -U <USER>，确认WSL环境可正常枚举共享列表，排除WSL网络拦截SMB请求的问题。
• 修正挂载参数：去掉冗余的addr字段，补充SMB版本、字符集、基础权限参数，卷配置修改为：

volumes:
  my_vol:
    driver_opts:
      type: cifs
      o: "username=<USER>,password=<PWD>,vers=3.0,iocharset=utf8,file_mode=0777,dir_mode=0777"
      device: "//xxx.xx.com/<MY_FOLDER>"

若共享服务部署在老版本Windows、NAS设备上，可将vers参数依次调整为2.0、1.0重试。

报错2：permission denied / utime操作失败 #

该报错是Docker完成CIFS挂载后，尝试修改卷目录默认时间属性时被共享端权限拦截导致，按以下步骤修复：

• 调整CIFS挂载参数：在o字段追加noperm参数，关闭CIFS层的权限校验，修改后参数为：

  o: "username=<USER>,password=<PWD>,vers=3.0,iocharset=utf8,file_mode=0777,dir_mode=0777,noperm"
  

• 修正共享端权限：在提供SMB共享的设备上，右键目标共享文件夹，进入「属性-共享-高级共享-权限」，给挂载使用的账号勾选「完全控制」「更改」「读取」权限；再切换到「安全」标签，给对应账号添加NTFS层的完全控制权限，避免权限拦截属性修改操作。
• 适配容器用户权限：在服务配置中添加user: root字段，强制容器使用root用户访问挂载目录，避免容器内普通用户UID/GID和CIFS共享映射的权限ID不匹配。

修改配置后先执行docker-compose down -v删除旧的异常卷，再执行docker-compose up -d启动服务，进入容器执行ls /mnt/my_vol，能正常看到共享目录内的文件即为挂载成功。

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