5

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?

2
  • did you ever find a solution for this? @Juan Leni May 2, 2020 at 19:16
  • 1
    I've had the same problem. Answer is "Use Docker Enging". Once, I've read this answer by rimelek. > People often open their Linux related questions in this category and Docker Desktop and Docker Engine is different so it is very important to know which one you use. I don’t know how it worked for you before, but as far as I know, you can’t mount unix sockets from the host to Docker Desktop. Docker Desktop runs the daemon in a virtual machine and mounting unix sockets is not supported.
    – ZYRBAGAN
    Nov 28, 2023 at 8:56

3 Answers 3

3

Had the exact same problem with a laptop. It worked for me if I added --net=host. Never bothered to figure out why.

2

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 references localhost 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.")

1
  • The terminology is correct. Docker uses a bridge device to setup this NAT.
    – muru
    Jul 20, 2021 at 23:16
2

Another thing you can try is to give necessary xhost permission. This solved my problem in ubuntu 20.04

In the bash issue the following

Allow X server connection

xhost +Local:*

And then

xhost

you should see more host Local

Then start with the docker run command adding --net=host gives me gui access.

credit to this post

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .