Hyperledger CLI容器未绑定主机卷，WSL中BYFN示例启动失败求助

看起来你在WSL环境下运行Hyperledger Fabric的BYFN示例时碰到了两个棘手的问题——脚本执行中断，还有CLI容器卷挂载异常。结合WSL和Fabric的常见兼容性问题，我整理了几个针对性的解决方案：

1. 优先升级到WSL 2（最关键的一步） #

WSL 1对Docker的卷挂载和网络支持存在诸多限制，这很可能是你遇到问题的根源。升级到WSL 2能大幅改善兼容性：

• 以管理员身份打开PowerShell，执行命令切换你的Ubuntu发行版到WSL 2：

  wsl --set-version Ubuntu-16.04 2
  

• 打开Docker Desktop，进入Settings > Resources > WSL Integration，勾选你的Ubuntu Xenial发行版，确保Docker能和WSL 2无缝协作。

2. 修复WSL文件权限与卷挂载配置 #

WSL默认的文件权限设置可能导致Docker无法正确访问主机目录，进而引发卷绑定失败：

• 在WSL终端中创建或编辑/etc/wsl.conf文件，添加以下配置：

  sudo nano /etc/wsl.conf
  

  写入内容：

  [automount]
  options = "metadata,umask=22,fmask=11"
  

• 保存后执行wsl --shutdown关闭WSL，重新打开终端让配置生效。
• 调整first-network目录的权限，确保Docker能读取：

  chmod -R 755 $GOPATH/fabric-samples/first-network
  

3. 清理现有Fabric资源后重新部署 #

残留的容器、网络或卷可能导致部署冲突，先彻底清理再重新运行：

• 执行BYFN脚本的清理命令：

  ./byfn.sh -m down
  

• 进一步清理Docker的无用资源：

  docker system prune -af
  

• 重新启动部署：

  ./byfn.sh -m up
  

4. 手动修复CLI容器的卷绑定配置 #

如果单独针对CLI容器的卷问题，可以直接修改docker-compose-cli.yaml文件：

• 打开first-network/docker-compose-cli.yaml，找到CLI服务的volumes段，确认所有主机路径都是WSL中的绝对路径，比如：

  volumes:
      - /var/run/:/host/var/run/
      - ./../chaincode/:/opt/gopath/src/github.com/chaincode
      - ./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
      - ./scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/
      - ./channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts/
  

• 保存后重新运行脚本，或者单独启动CLI容器测试：

  docker-compose -f docker-compose-cli.yaml up -d
  

如果以上方法还没解决问题，你可以查看CLI容器的日志获取更详细的错误信息：

docker logs cli

根据日志里的具体报错再进一步排查。

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