看起来你在Docker Swarm模式下使用NFS卷遇到了坑——单机Compose里好好的，一上Swarm就出问题，这种情况我碰到过好几次，主要是Swarm对卷的处理逻辑和单机不一样，咱们一步步来排查解决：

1. 先确认所有Swarm工作节点的NFS挂载一致性 #

Swarm会把容器调度到集群里的任意工作节点，如果某个节点没有正确挂载NFS共享路径，那调度到这个节点的容器肯定会异常。你需要登录每一个Swarm工作节点，执行以下命令检查：

mount | grep nfs

确保每个节点的/mnt/nfs/var/nfsshare路径都已正确挂载，并且权限和服务器端一致（比如容器内运行用户的UID/GID要和NFS共享目录的权限匹配，避免读写被拒）。

2. 改用Swarm兼容的命名卷配置，而非直接绑定挂载 #

单机Compose里直接用绑定挂载（/mnt/nfs/var/nfsshare:/container/path）没问题，但Swarm更推荐使用命名卷+NFS驱动配置，这样Swarm会自动在每个节点处理卷的挂载，不需要手动在每个节点预先挂载NFS。

修改你的docker-compose.yml，定义NFS类型的命名卷：

version: "3.8"

volumes:
  nfs-shared-storage:
    driver: local
    driver_opts:
      type: nfs
      o: addr=<你的NFS服务器IP>,rw,nolock,soft,rsize=8192,wsize=8192
      device: ":/var/nfsshare"

services:
  # 示例服务1
  service-a:
    image: your-image-a
    volumes:
      - nfs-shared-storage:/data
    deploy:
      replicas: 2
      # 其他部署配置

  # 示例服务2
  service-b:
    image: your-image-b
    volumes:
      - nfs-shared-storage:/data
    deploy:
      replicas: 2
      # 其他部署配置

这样配置后，Swarm会自动在容器调度到的节点上挂载NFS卷，不需要你手动在每个节点做挂载操作。

3. 检查安全模块（SELinux/AppArmor）的限制 #

部分Linux发行版的SELinux或AppArmor会阻止容器访问NFS挂载的目录。你可以临时关闭SELinux测试：

setenforce 0

如果关闭后容器恢复正常，就需要配置SELinux规则允许容器访问NFS路径，比如：

chcon -Rt svirt_sandbox_file_t /mnt/nfs/var/nfsshare

对于AppArmor，检查是否有针对Docker的配置文件限制了NFS访问，必要时调整规则。

4. 查看日志定位具体错误 #

如果以上步骤还没解决问题，一定要看容器或服务的日志，这是定位问题的关键：

• 查看Swarm服务日志：

docker service logs <你的服务名称>

• 如果容器能启动但异常，查看单个容器日志：

docker logs <容器ID>

日志里通常会给出具体错误，比如“permission denied”（权限问题）、“connection refused”（NFS服务器连接问题）等，根据错误再针对性解决。

5. 确认NFS服务器的防火墙规则 #

NFS服务需要开放多个端口（默认2049，还有rpcbind的111端口等），如果Swarm节点和NFS服务器不在同一局域网，一定要确保NFS服务器的防火墙允许所有Swarm节点访问这些端口，否则会出现挂载超时或失败的情况。

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