8

I am currently trying to run some GUI apps in docker containers. I have been trying the ones by jessie frazelle at github. However I can build the images (or get from docker hub) and run them without any visible errors but, the windows don't display (i cant see the app).

I am running Docker version 1.13.1 on Ubuntu 16.04

The 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 run command i am using 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 many sources, I can see that the above should work, andmost people are saying that the following lines are required in the run command,

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

but still I cant get the window to display.

  1. How can I get this to work?
  2. What am I fundamentally missing?

Any help would be appreciated.

David Brough
  • 101
  • 1
  • 1
  • 5
  • This has some good info: http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/. You'll probably need to mess with user mapping. – johnharris85 Feb 12 '17 at 03:41
  • Did you try it with `-e DISPLAY=$DISPLAY`? Are there any errors from when the container executes `libreoffice`? – Alvaro Carvajal Feb 12 '17 at 06:41
  • Also, are you running the container in the same host where you have your X display, or from a remote host? – Alvaro Carvajal Feb 12 '17 at 06:51
  • @johnharris85 - thank for the resource, I will have a good read. – David Brough Feb 12 '17 at 07:11
  • @Alvaro Carvajal - yes I tried that line and I got an error saying that no display is available. I am currently trying it on my local machine, but want to try remote once ive got this working. Is there a difference in the setoup between local vs remote. – David Brough Feb 12 '17 at 07:11
  • @DavidBrough - yes, there is a difference. Usually if you're running the container from a terminal where you already have access to the X display, all that you need to pass to the container is `-e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix` (and the docker image itself must have been created with any packages the application may need; for instance I had to install libxext6 libxrender1 libxtst6 libxi6 on a container with a Java app developed in-house). – Alvaro Carvajal Feb 12 '17 at 16:32
  • @DavidBrough - If the container is being run from a remote machine, DISPLAY should be set to an address and display that can re resolved by the container and the display host must be configured to allow X connections from remote hosts – Alvaro Carvajal Feb 12 '17 at 16:33
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. Also see [Where do I post questions about Dev Ops?](http://meta.stackexchange.com/q/134306) – jww Feb 12 '17 at 19:09

1 Answers1

1

To be able to communicate with the X server, the user that runs the app has to be allowed to communicate with the X server. So I think you have two options:

  1. Allow the user you have in the container to connect to the X server. If your app is run with user 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 either way...)

  1. Add a user in the container that matches your user session. If the user you are using in the host system has UID = 1000, you can create a dummy user inside the container:

    $ useradd -u 1000 my_user

And then use that user to run your app inside the container. This doesn't require any change in the accepted hosts (as user 1000 is already capable of connection).

Looking at the two options, the second seems better, because it does not require any change in the host system, and if you need to use this container in other systems that the main user could not match UID=1000, you can make the container receive the correct uid from an env var, and then set up the correct user (useradd + chown program files).

Wyck
  • 10,311
  • 6
  • 39
  • 60
Salem
  • 12,808
  • 4
  • 34
  • 54
  • 3
    I tried this and it worked, so at least I know the container is setup and running correctly. I have read that this method is insecure so will read the link that @johnharris85 posted above and others to try and find a more secure way. – David Brough Feb 12 '17 at 07:16
  • 1
    @DavidBrough Yes, allowing everything is a little insecure, but the idea was to check if was this that was blocking the connection. I've edited the response with other alternatives. Good luck – Salem Feb 12 '17 at 14:39
  • +1 Some of the machines we deal with are totally locked down in other ways (only ssh access through proper key and tunnelling on that) so no need to security-shame developers who want to do this in DEV environments. – lucid_dreamer May 24 '18 at 18:53