X11 redirecting a GUI application to a Docker container

I am currently trying to run some graphical applications in docker containers. I am trying to use jessie frazelle on github . However, I can create images (or get from the docker hub) and run them without visible errors, but the windows do not appear (I can not see the application).

I am running Docker version 1.13.1 on Ubuntu 16.04

Image is created from:

FROM debian:stretch MAINTAINER Jessie Frazelle < jess@linux.com > RUN apt-get update && apt-get install -y \ libreoffice \ --no-install-recommends \ && rm -rf /var/lib/apt/lists/* ENTRYPOINT [ "libreoffice" ] 

the start command that I use is below:

 docker run -d \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -v /etc/localtime:/etc/localtime \ -e DISPLAY=unix$DISPLAY -v $HOME/Documents:/root/Documents \ -e GDK_SCALE \ -e GDK_DPI_SCALE \ --name libreoffice \ jess/libreoffice 

After searching for many sources, I see that the above should work, and most people say that the following lines are required in the launch command:

  -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY 

but still i cant get a window to display.

  • How can I make this work?
  • What am I fundamentally missing?

Any help would be appreciated.

+7
linux docker containers dockerfile x11-forwarding
source share
1 answer

In order to be able to communicate with the X server, the user who you launched the application must be allowed to communicate with the X server. So I think you have two options:

1) Allow the user in the container to connect to the X server. If your application runs as root inside the container, you can use:

 $ xhost +SI:localuser:root 

(I don't know the security implications of this, but root should be able to connect anyway ...)

2) Add the user to the container that matches your user session. If the user you are using on the main system has UID = 1000, you can create a dummy user inside the container:

 $ useradd -u 1000 my_user 

And then use this user to launch your application inside the container. This does not require any changes to the attacked hosts (since user 1000 is already able to connect).

Considering the two options, the second one looks better, because it does not require any changes in the host system, and if you need to use this container on other systems that cannot correspond to the main user UID = 1000, you can have the container get the correct uid from env var, and then configured the correct user file (useradd + chown).

+1
source share

All Articles