Docker容器运行GUI应用：--net=host生效原因及网络隔离保留方案

为什么--net=host能解决GUI显示问题？ #

这背后主要和X11的访问机制以及Docker的网络模式有关：

1. Xserver的访问控制：Kubuntu自带的Xorg服务器默认只允许同一网络命名空间内的进程连接到DISPLAY=:0。Docker默认使用桥接网络模式，容器会拥有独立的网络命名空间，和主机不在同一个网络环境里——哪怕你挂载了/tmp/.X11-unix的socket文件，容器内的进程也无法通过常规方式获得Xserver的访问授权，所以会抛出Can't open display: :0的错误。
2. --net=host的作用：这个参数让容器直接共享主机的网络命名空间，容器内的进程相当于“伪装”成主机本地进程运行，自然能被Xserver的访问策略认可，顺利连接到显示端口。

另外还有个隐藏的点：你没挂载主机的~/.Xauthority文件（X11的访问密钥文件），默认桥接模式下容器没有这个授权文件，就算有socket也没权限访问Xserver；而--net=host时，容器间接利用了主机的授权上下文，绕过了这个限制。

不使用--net=host（保持网络隔离）的解决方案 #

你可以通过正确配置X11授权和挂载必要文件，让容器合法访问主机Xserver，同时保留网络隔离：

方法1：临时放宽权限（适合快速测试）

在主机终端先执行这条命令，允许本地root用户（容器默认用户）访问Xserver：

xhost +local:root

然后启动容器时，加上挂载~/.Xauthority的参数（替换成你的实际用户目录）：

docker run --gpus all -it -p "8888:8888" \
  -v "/home/gillian/Documents/deeplearning/:/deeplearning/" \
  --env=DISPLAY=$DISPLAY \
  --env=QT_X11_NO_MITSHM=1 \
  -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
  -v $HOME/.Xauthority:/root/.Xauthority:rw \
  pytorch

测试完成后，记得恢复Xserver的安全设置：

xhost -local:root

方法2：安全授权方式（推荐）

不需要放宽全局权限，而是把容器的授权信息加入Xserver的访问列表：

1. 先在主机终端获取Xserver的授权密钥：

XAUTH=$(xauth list $DISPLAY | tail -1 | awk '{print $3}')

2. 启动容器时，传递密钥并设置临时授权文件：

docker run --gpus all -it -p "8888:8888" \
  -v "/home/gillian/Documents/deeplearning/:/deeplearning/" \
  --env=DISPLAY=$DISPLAY \
  --env=QT_X11_NO_MITSHM=1 \
  -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
  --env=XAUTHORITY=/tmp/.docker.xauth \
  -v /tmp/.docker.xauth:/tmp/.docker.xauth:rw \
  pytorch \
  bash -c "xauth add $DISPLAY . $XAUTH && exec bash"

这个方法会在容器内临时添加合法的Xserver授权条目，既保持了网络隔离，又保证了访问安全性。

额外注意事项

• 确保主机用户对/tmp/.X11-unix目录有读写权限，容器内的用户（默认root）也能访问挂载的socket文件。
• 如果容器内使用非root用户，需要调整~/.Xauthority的挂载路径到容器内用户的home目录，并确保该用户有权限读取文件。

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