Docker Desktop升级后bind mount的docker.sock权限未保留问题排查

问题重现 #

执行以下命令挂载docker.sock到容器：

docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker:cli ls -l /var/run/docker.sock

输出显示套接字组所有权变为root:root：

srw-rw---- 1 root root 0 Apr 10 19:39 /var/run/docker.sock

原因分析 #

Docker Desktop 4.29对WSL2集成的权限模型做了调整：Windows上的/var/run/docker.sock实际指向WSL2虚拟机内的套接字文件，4.27版本中该文件组为docker（通常GID=999），但4.29版本为简化跨WSL发行版的权限映射，将组所有权改为root（GID=0）。这一调整是为了避免不同WSL发行版中docker组GID不一致引发的权限冲突。

是Bug还是设计变更？ #

这是有意的设计变更，并非Bug。Docker官方在4.29版本更新日志中明确提及了WSL集成的权限优化，目的是提升跨环境下权限配置的一致性。

当前适配的挂载方式 #

推荐两种更稳定的适配方案：

• 方案1：同步容器与主机的docker组GID
  先在WSL2终端中获取主机docker组的GID：

  getent group docker | cut -d: -f3
  

  假设输出为999，启动容器时通过--group-add参数添加该GID，让容器内docker组拥有套接字权限：

  docker run -it -v /var/run/docker.sock:/var/run/docker.sock --group-add 999 docker:cli ls -l /var/run/docker.sock
  

• 方案2：使用Docker Desktop内置的TCP代理
  无需挂载套接字，直接通过host.docker.internal访问Docker API：

  docker run -it docker:cli docker -H tcp://host.docker.internal:2375 ps
  

  若启用了TLS加密，使用端口2376即可。这种方式彻底规避了套接字权限问题，更适配Windows Docker Desktop环境。

临时方案的局限性 #

你提到的两种临时方法存在不足：

• 启动时执行chown root:docker /var/run/docker.sock：需额外命令，不适用于Docker Compose等编排场景，容器重启后需重复操作。
• 回退至4.27版本：虽能恢复旧行为，但无法获取新版本的功能更新与安全修复。

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