I have a docker container and I want to run an app that requires X11. I want to expose that in the host. This is actually working well in a notebook but fails in a desktop.
More info:
I am launching docker with the correct arguments:
docker run -it --rm \
--privileged \
-e DISPLAY \
-v /tmp/.X11-unix:/tmp/.X11-unix:ro \
.... not related options ....
$(DOCKER_IMAGE) \
xclock
In a notebook (Ubuntu 19.10) works great BUT when I try the same in a desktop (Ubuntu 19.10), I get Error: Can't open display: :1
There is somehow something different and I cannot find out what the difference is.
I have already:
- Disabled access control
xhost +
- There is no
~/.Xauthority
file - No firewall enabled
- Containers are identical (both computers download the image from Dockerhub).
- This is not about SSH at all, so X11 forwarding is not relevant.
- Both computers are using X11 (no wayland involved)
I have noticed that notebook uses :0
and desktop :1
but I don't think that is relevant.
Question: Are there any log files that I could look at? Any tips on debugging the issue?
Had the exact same problem with a laptop. It worked for me if I added --net=host. Never bothered to figure out why.
An old question, but as mentioned in another answer,
--net=host
worked for me when I just ran into this same problem just now (Ubuntu 16 LTS server and Mac OS client with XQuartz, via SSH).I think this is because, if
$DISPLAY
referenceslocalhost
and you're using the default docker network setup (--network=bridge
), you get a separate IP address for the container and "localhost" inside the container refers to a different place than it does on the host OS. I still wasn't able to get my X server listening to incoming connections even with the right address with the container in bridge mode, but I think that's something about my own setup, separate from docker (the X server's port on the host looks open when checking localhost but closed when using its external-facing address). But whatever the case, if you're OK with the container and the host sharing the exact same network stack then it sounds like host networking should be fine.On a side note I think they're jumbling up some terminology since docker's "bridge" sounds a lot more like NAT rather than bridging, and this page about host networking actually references NAT in passing as though that's the alternate to host networking:
https://docs.docker.com/network/host/
Edit: As per maru's comment I think their terminology is actually correct: they define a bridge at the ethernet level, and the implicit NAT setup that comes along with it is an IP thing, so the configuration is on two different layers. (I think I'm too used to VM software like VirtualBox offering an either/or between "NAT" and "bridged adapter.")