Can you run GUI applications in a Docker container

Question

How can you run GUI applications in a Docker container   Are there any images that set up vncserver or something so that you can - for example - add an extra speedbump sandbox around say Firefox

User · Answer

I just found this blog entry and want to share it here with you because I think it is the best way to do it and it is so easy.

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/

PROS:
+ no x server stuff in the docker container
+ no vnc client/server needed
+ no ssh with x forwarding
+ much smaller docker containers

CONS:
- using x on the host (not meant for secure-sandboxing)

in case the link will fail someday I have put the most important part here:
dockerfile:

FROM ubuntu:14.04

RUN apt-get update && apt-get install -y firefox

# Replace 1000 with your user / group id
RUN export uid=1000 gid=1000 && \
    mkdir -p /home/developer && \
    echo "developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash" >> /etc/passwd && \
    echo "developer:x:${uid}:" >> /etc/group && \
    echo "developer ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/developer && \
    chmod 0440 /etc/sudoers.d/developer && \
    chown ${uid}:${gid} -R /home/developer

USER developer
ENV HOME /home/developer
CMD /usr/bin/firefox

build the image:

docker build -t firefox .

and the run command:

docker run -ti --rm \
   -e DISPLAY=$DISPLAY \
   -v /tmp/.X11-unix:/tmp/.X11-unix \
   firefox

of course you can also do this in the run command with sh -c "echo script-here"

HINT: for audio take a look at: https://stackoverflow.com/a/28985715/2835523

User · Answer

There is another solution by lord garbage to run GUI apps in a container without using VNC  SSH and X11 forwarding  It is mentioned here too

User · Answer

Based on J  rgen Weigert s answer  I have some improvement   docker build -t xeyes -  lt  lt    EOF   FROM debian RUN apt-get update RUN apt-get install -qqy x11-apps ENV DISPLAY  0 CMD xeyes   EOF   XSOCK  tmp  X11-unix XAUTH DIR  tmp  docker xauth XAUTH  XAUTH DIR  xauth mkdir -p  XAUTH DIR  amp  amp  touch  XAUTH xauth nlist  DISPLAY   sed -e  s       ffff     xauth -f  XAUTH nmerge - docker run -ti -v  XSOCK  XSOCK -v  XAUTH DIR  XAUTH DIR -e XAUTHORITY  XAUTH xeyes   The only difference is that it creates a directory  XAUTH DIR which is used to place  XAUTH file and mount  XAUTH DIR directory instead of  XAUTH file into docker container   The benefit of this method is that you can write a command in  etc rc local which is to create a empty folder named  XAUTH DIR in  tmp and change its mode to 777     tr   n    000   lt   etc rc local   sudo tee  etc rc local  gt  dev null sudo sed -i  s  x00XAUTH DIR    x00 x00  x00    etc rc local  gt  dev null tr   000    n   lt   etc rc local   sudo tee  etc rc local  gt  dev null sudo sed -i  s  exit 0    XAUTH DIR  tmp  docker xauth  rm -rf  XAUTH DIR  install -m 777 -d  XAUTH DIR n nexit 0    etc rc local   When system restart  before user login  docker will mount the  XAUTH DIR directory automatically if container s restart policy is  always   After user login  you can write a command in    profile which is to create  XAUTH file  then the container will automatically use this  XAUTH file   tr   n    000   lt     profile   sudo tee    profile  gt  dev null sed -i  s  x00XAUTH DIR   - x00  x00      profile tr   000    n   lt     profile   sudo tee    profile  gt  dev null echo  XAUTH DIR  tmp  docker xauth  XAUTH   XAUTH DIR  xauth  touch   XAUTH  xauth nlist   DISPLAY   sed -e  s       ffff     xauth -f   XAUTH nmerge -   gt  gt     profile   Afterall  the container will automatically get the Xauthority file every time the system restart and user login

User · Answer

Docker with BRIDGE network  for Ubuntu 16 04 with display manager lightdm   cd  etc lightdm lightdm conf d sudo nano user conf   Seat    xserver-allow-tcp true xserver-command X -listen tcp   you can use more private permissions  xhost    docker run --volume   HOME  Xauthority  root  Xauthority rw  --env  DISPLAY  HOST IP IN BRIDGE NETWORK 0  --net bridge  container name

User · Answer

For OpenGL rendering with the Nvidia driver  use the following image   https   github com thewtex docker-opengl-nvidia  For other OpenGL implementations  make sure the image has the same implementation as the host

User · Answer

Here s a lightweight solution that avoids having to install any X server  vnc server or sshd daemon on the container  What it gains in simplicity it loses in security and isolation   It assumes that you connect to the host machine using ssh with X11 forwarding   In the sshd configuration of the host  add the line  X11UseLocalhost no   So that the forwarded X server port on the host is opened on all interfaces  not just lo  and in particular on the Docker virtual interface  docker0   The container  when run  needs access to the  Xauthority file so that it can connect to the server  In order to do that  we define a read-only volume pointing to the home directory on the host  maybe not a wise idea   and also set the XAUTHORITY variable accordingly   docker run -v  HOME  hosthome ro -e XAUTHORITY  hosthome  Xauthority   That is not enough  we also have to pass the DISPLAY variable from the host  but substituting the hostname by the ip   -e DISPLAY   echo  DISPLAY   sed  s        hostname -i        We can define an alias    alias dockerX11run  docker run -v  HOME  hosthome ro -e XAUTHORITY  hosthome  Xauthority -e DISPLAY   echo  DISPLAY   sed  s        hostname -i         And test it like this   dockerX11run centos xeyes

User · Answer

Yet another answer in case you already built the image     invoke docker w o sudo  How to fix docker  Got permission denied issue  share the same USER  amp  home  amp  passwd between host and container share  tips  use user id instead of user name  the dev folder for driver dependent libs to work well  plus X11 forward        docker run --name CONTAINER NAME --network host --privileged         -v  dev  dev         -v  echo     home   USER          -p 8080 80         --user  id -u   USER           --env  DISPLAY          --volume   etc group  etc group ro          --volume   etc passwd  etc passwd ro          --volume   etc shadow  etc shadow ro          --volume   etc sudoers d  etc sudoers d ro          --volume   tmp  X11-unix  tmp  X11-unix rw          -it REPO TAG  bin bash   you may ask  whats the point to use docker if so many things are the same  well  one reason I can think of is to overcome the package depency hell  https   en wikipedia org wiki Dependency hell    So this type of usage is more suitable for developer I think

User · Answer

Xauthority becomes an issue with newer systems  I can either discard any protection with xhost   before running my docker containers  or I can pass in a well prepared Xauthority file  Typical Xauthority files are hostname specific  With docker  each container can have a different host name  set with docker run -h   but even setting the hostname of the container identical to the host system did not help in my case  xeyes  I like this example  simply would ignore the magic cookie and pass no credentials to the server  Hence we get an error message  No protocol specified Cannot open display   The Xauthority file can be written in a way so that the hostname does not matter  We need to set the Authentication Family to  FamilyWild   I am not sure  if xauth has a proper command line for this  so here is an example that combines xauth and sed to do that  We need to change the first 16 bits of the nlist output  The value of FamilyWild is 65535 or 0xffff   docker build -t xeyes -  lt  lt    EOF   FROM debian RUN apt-get update RUN apt-get install -qqy x11-apps ENV DISPLAY  0 CMD xeyes   EOF   XSOCK  tmp  X11-unix XAUTH  tmp  docker xauth xauth nlist  0   sed -e  s       ffff     xauth -f  XAUTH nmerge - docker run -ti -v  XSOCK  XSOCK -v  XAUTH  XAUTH -e XAUTHORITY  XAUTH xeyes

User · Answer

You can allow the Docker user  here  root  to access the X11 display   XSOCK  tmp  X11-unix xhost  SI localuser root  docker run -t -i --rm -v  XSOCK  XSOCK ro -e DISPLAY unix  DISPLAY  image  xhost -SI localuser root

User · Answer

You can simply install a vncserver along with Firefox     I pushed an image  vnc firefox  here   docker pull creack firefox-vnc  The image has been made with this Dockerfile     Firefox over VNC     VERSION               0 1   DOCKER-VERSION        0 2  FROM    ubuntu 12 04   Make sure the package repository is up to date RUN     echo  deb http   archive ubuntu com ubuntu precise main universe   gt   etc apt sources list RUN     apt-get update    Install vnc  xvfb in order to create a  fake  display and firefox RUN     apt-get install -y x11vnc xvfb firefox RUN     mkdir    vnc   Setup a password RUN     x11vnc -storepasswd 1234    vnc passwd   Autostart firefox  might not be the best way to do it  but it does the trick  RUN     bash -c  echo  firefox   gt  gt    bashrc    This will create a Docker container running VNC with the password 1234   For Docker version 18 or newer   docker run -p 5900 5900 -e HOME   creack firefox-vnc x11vnc -forever -usepw -create   For Docker version 1 3 or newer   docker run -p 5900 -e HOME   creack firefox-vnc x11vnc -forever -usepw -create   For Docker before version 1 3   docker run -p 5900 creack firefox-vnc x11vnc -forever -usepw -create

User · Answer

If you want to run a GUI application headless  then read here  What you have to do is to create a virtual monitor with xvfb or other similar software  This is very helpful if you want to run Selenium tests for example with browsers   Something not mentioned anywhere is that some software actually themselves use sand-boxing with Linux containers  So for example Chrome will never run normally if you don t use the appropriate flag --privileged when running the container

User · Answer

The solution given at http   fabiorehm com blog 2014 09 11 running-gui-apps-with-docker  does seem to be an easy way of starting GUI applications from inside the containers   I tried for firefox over ubuntu 14 04  but I found that a small additional change is required to the solution posted by the author   Specifically  for running the container  the author has mentioned       docker run -ti --rm       -e DISPLAY  DISPLAY       -v  tmp  X11-unix  tmp  X11-unix       firefox   But I found that  based on a particular comment on the same site  that two additional options      -v  HOME  Xauthority  HOME  Xauthority   and      -net host    need to be specified while running the container for firefox to work properly       docker run -ti --rm       -e DISPLAY  DISPLAY       -v  tmp  X11-unix  tmp  X11-unix       -v  HOME  Xauthority  HOME  Xauthority       -net host       firefox   I have created a docker image with the information on that page and these additional findings  https   hub docker com r amanral ubuntu-firefox

User · Answer

OSX  J  rgen Weigert has the best answer that worked for me on Ubuntu  however on OSX  docker runs inside of VirtualBox and so the solution doesn t work without some more work   I ve got it working with these additional ingredients    Xquartz  OSX no longer ships with X11 server  socket forwarding with socat  brew install socat  bash script to launch the container   I d appreciate user comments to improve this answer for OSX  I m not sure if socket forwarding for X is secure  but my intended use is for running the docker container locally only   Also  the script is a bit fragile in that it s not easy to get the IP address of the machine since it s on our local wireless so it s always some random IP   The BASH script I use to launch the container      usr bin env bash  CONTAINER py3 2016-03-23-rc3 COMMAND  bin bash NIC en0    Grab the ip address of this box IPADDR   ifconfig  NIC   grep  inet     awk   print  2     DISP NUM   jot -r 1 100 200     random display number between 100 and 200  PORT NUM    6000   DISP NUM     so multiple instances of the container won t interfer with eachother  socat TCP-LISTEN   PORT NUM  reuseaddr fork UNIX-CLIENT    DISPLAY   2 gt  amp 1  gt   dev null  amp   XSOCK  tmp  X11-unix XAUTH  tmp  docker xauth  USER    touch  XAUTH xauth nlist  DISPLAY   sed -e  s       ffff     xauth -f  XAUTH nmerge -  docker run       -it       --rm       --user  USER       --workdir   Users  USER        -v   Users  USER  home  USER rw        -v  XSOCK  XSOCK rw       -v  XAUTH  XAUTH rw       -e DISPLAY  IPADDR  DISP NUM       -e XAUTHORITY  XAUTH        CONTAINER        COMMAND  rm -f  XAUTH kill  1         kill the socat job launched above   I m able to get xeyes and matplotlib working with this approach   Windows 7   It s a bit easier on Windows 7  with MobaXterm    Install MobaXterm for windows Start MobaXterm Configure X server  Settings -  X11  tab  -  set X11 Remote Access to full Use this BASH script to launch the container   run docker bash      usr bin env bash  CONTAINER py3 2016-03-23-rc3 COMMAND  bin bash DISPLAY    hostname  0  USER   whoami   docker run       -it       --rm       --user  USER       --workdir   home  USER        -v   c Users  USER  home  USER rw        -e DISPLAY        CONTAINER        COMMAND

User · Answer

The other solutions should work  but here is a solution for docker-compose   To fix that error  you need to pass  DISPLAY and  X11-unix to docker  as well as grant the user who started docker access to xhost   Within docker-compose yml file   version   2  services      node          build            container name  node         environment              - DISPLAY         volumes              -  tmp  X11-unix  tmp  X11-unix   In terminal or script    xhost  si localuser  USER xhost  local docker export DISPLAY  DISPLAY docker-compose up

User · Answer

I managed to run a video stream from an USB camera using opencv in docker by following these steps    Let docker access the X server  xhost  local docker  Create the X11 Unix socket and the X authentication file  XSOCK  tmp  X11-unix XAUTH  tmp  docker xauth  Add proper permissions  xauth nlist  DISPLAY   sed -e  s       ffff     xauth -f  XAUTH nmerge -  Set the Qt rendering speed to  native   so it doesn t bypass the X11 rendering engine  export QT GRAPHICSSYSTEM native  Tell Qt to not use MIT-SHM  shared memory  - that way it should be also safer security-wise  export QT X11 NO MITSHM 1  Update the docker run command  docker run -it              -e DISPLAY  DISPLAY              -e XAUTHORITY  XAUTH              -v  XSOCK  XSOCK              -v  XAUTH  XAUTH              --runtime nvidia              --device  dev video0  dev video0              nvcr io nvidia pytorch 19 10-py3    Note  When you finish the the project  return the access controls at their default value - xhost -local docker  More details  Using GUI s with Docker  Credit  Real-time and video processing object detection using Tensorflow  OpenCV and Docker

User · Answer

OSX  10 13 6  high sierra   Similar to  Nick s answer  but his solution did not work for me   First install socat by doing brew install socat  and install XQuartz  https   www xquartz org    Then followed these steps here  http   fabiorehm com blog 2014 09 11 running-gui-apps-with-docker   in the comments section   1  in one mac terminal i started   socat TCP-LISTEN 6000 reuseaddr fork UNIX-CLIENT    DISPLAY    2  and in another mac terminal I ran   docker run -ti --rm   -e DISPLAY   ipconfig getifaddr en0  0   -v  tmp  X11-unix  tmp  X11-unix   firefox   I was also able to launch CLion from my debian docker container too

User · Answer

With docker data volumes it s very easy to expose xorg s unix domain socket inside the container   For example  with a Dockerfile like this   FROM debian RUN apt-get update RUN apt-get install -qqy x11-apps ENV DISPLAY  0 CMD xeyes   You could do the following     docker build -t xeyes -  lt  Dockerfile   XSOCK  tmp  X11-unix X0   docker run -v  XSOCK  XSOCK xeyes   This of course is essentially the same as X-forwarding   It grants the container full access to the xserver on the host  so it s only recommended if you trust what s inside   Note  If you are concerned about security  a better solution would be to confine the app with mandatory- or role-based-access control   Docker achieves pretty good isolation  but it was designed with a different purpose in mind   Use AppArmor  SELinux  or GrSecurity  which were designed to address your concern

User · Answer

You can also use subuser  https   github com timthelion subuser  This allows you to package many gui apps in docker   Firefox and emacs have been tested so far   With firefox  webGL doesn t work though   Chromium doesn t work at all   EDIT  Sound works   EDIT2  In the time since I first posted this  subuser has progressed greatly  I now have a website up subuser org  and a new security model for connecting to X11 via XPRA bridging

User · Answer

I m late to the party  but for Mac users who don t want to go down the XQuartz path  here is a working example that builds a Fedora Image  with a Desktop Environment  xfce  using Xvfb and VNC  It s simple  and works    https   github com ddual docker recipes fedora-with-an-x-window-system https   github com ddual docker recipes tree master fedora gui   On a Mac  you can just access it using the Screen Sharing  default  application  connecting to localhost 5901   Dockerfile   FROM fedora  USER root    Set root password  so I know it for the future RUN echo  root password123    chpasswd    Install Java  Open SSL  etc  RUN dnf update -y --setopt deltarpm false      amp  amp  dnf install -y --setopt deltarpm false                   openssl x86 64                               java-1 8 0-openjdk x86 64                    xorg-x11-server-Xvfb                         x11vnc                                       firefox                                       xfce-desktop-environment      amp  amp  dnf clean all    Create developer user  password  password123  uid  11111  RUN useradd -u 11111 -g users -d  home developer -s  bin bash -p   echo password123   openssl passwd -1 -stdin  developer    Copy startup script over to the developer home COPY start-vnc sh  home developer start-vnc sh RUN chmod 700  home developer start-vnc sh RUN chown developer users  home developer start-vnc sh    Expose VNC  SSH EXPOSE 5901 22    Set up VNC Password and DisplayEnvVar to point to Display1Screen0 USER developer ENV  DISPLAY  1 0 RUN  mkdir    x11vnc RUN  x11vnc -storepasswd letmein    x11vnc passwd  WORKDIR  home developer CMD    home developer start-vnc sh     start-vnc sh     bin sh  Xvfb  1 -screen 0 1024x768x24  amp  sleep 5 x11vnc -noxdamage -many -display  1 -rfbport 5901 -rfbauth    x11vnc passwd -bg sleep 2 xfce4-session  amp   bash   while true  do sleep 1000  done   Check the linked readme for build and run commands if you want need

User · Answer

While the answer by J  rgen Weigert essentially covers this solution  it wasn t clear to me at first what was being described there  So I ll add my take on it  in case anyone else needs clarification    First off  the relevant documentation is the X security manpage   Numerous online sources suggest just mounting the X11 unix socket and the    Xauthority file into the container  These solutions often work by luck  without really understanding why  e g  the container user ends up with the same UID as the user  so there s no need for magic key authorization    First off  the Xauthority file has mode 0600  so the container user won t be able to read it unless it has the same UID    Even if you copy the file into the container  and change the ownership  there s still another problem  If you run xauth list on the host and container  with the same Xauthority file  you ll see different entries listed  This is because xauth filters the entries depending on where it s run   The X client in the container  i e  GUI app  will behave the same as xauth  In other words  it doesn t see the magic cookie for the X session running on the user s desktop  Instead  it sees the entries for all the  remote  X sessions you ve opened previously  explained below    So  what you need to do is add a new entry with the hostname of the container and the same hex key as the host cookie  i e  the X session running on your desktop   e g    containerhostname unix 0   MIT-MAGIC-COOKIE-1    lt shared hex key gt    The catch is that the cookie has to be added with xauth add inside the container   touch    Xauthority xauth add containerhostname unix 0    lt shared hex key gt    Otherwise  xauth tags it in a way that it s only seen outside the container   The format for this command is   xauth add hostname  DISPLAY protocol hexkey   Where   represents the MIT-MAGIC-COOKIE-1 protocol    Note  There s no need to copy or bind-mount  Xauthority into the container  Just create a blank file  as shown  and add the cookie    J  rgen Weigert s answer gets around this by using the FamilyWild connection type to create a new authority file on the host and copy it into the container  Note that it first extracts the hex key for the current X session from    Xauthority using xauth nlist    So the essential steps are    Extract the hex key of the cookie for the user s current X session   Create a new Xauthority file in the container  with the container hostname and the shared hex key  or create a cookie with the FamilyWild connection type      I admit that I don t understand very well how FamilyWild works  or how xauth or X clients filter entries from the Xauthority file depending where they re run  Additional information on this is welcome     If you want to distribute your Docker app  you ll need a start script for running the container that gets the hex key for the user s X session  and imports it into the container in one of the two ways explained previously    It also helps to understand the mechanics of the authorization process    An X client  i e  GUI application  running in the container looks in the Xauthority file for a cookie entry that matches the container s hostname and the value of  DISPLAY   If a matching entry is found  the X client passes it with its authorization request to the X server  through the appropriate socket in the  tmp  X11-unix directory mounted in the container    Note  The X11 Unix socket still needs to be mounted in the container  or the container will have no route to the X server  Most distributions disable TCP access to the X server by default for security reasons    For additional information  and to better grasp how the X client server relationship works  it s also helpful to look at the example case of SSH X forwarding     The SSH server running on a remote machine emulates its own X server  It sets the value of  DISPLAY in the SSH session to point to its own X server   It uses xauth to create a new cookie for the remote host  and adds it to the Xauthority files for both the local and remote users   When GUI apps are started  they talk to SSH s emulated X server  The SSH server forwards this data back to the SSH client on your local desktop  The local SSH client sends the data to the X server session running on your desktop  as if the SSH client was actually an X client  i e  GUI app    The X server uses the received data to render the GUI on your desktop  At the start of this exchange  the remote X client also sends an authorization request  using the cookie that was just created  The local X server compares it with its local copy

User · Answer

Sharing host display  0  as stated in some other answers  has two drawbacks     It breaks container isolation due to some X security leaks  For example  keylogging with xev or xinput is possible  and remote control of host applications with xdotool   Applications can have rendering glitches and bad RAM access errors due to missing shared memory for X extension MIT-SHM   Can also be fixed with isolation degrading option --ipc host     Below an example script to run a docker image in Xephyr that addresses this issues     It avoids X security leaks as the docker applications run in a nested X server   MIT-SHM is disabled to avoid RAM access failures  Container security is improved with --cap-drop ALL --security-opt no-new-privileges  Also the container user is not root  An X cookie is created to restrict access to Xephyr display    The script expects some arguments  first a host window manager to run in Xephyr  second a docker image  optionally third an image command to be executed   To run a desktop environment in docker  use     instead of a host window manager   Closing Xephyr window terminates docker container applications  Terminating the dockered applications closes Xephyr window   Examples    xephyrdocker  openbox --sm-disable  x11docker lxde pcmanfm xephyrdocker     x11docker lxde xephyrdocker xfwm4 --device  dev snd jess nes  games zelda rom   xephyrdocker script       bin bash     Xephyrdocker      Example script to run docker GUI applications in Xephyr      Usage      Xephyrdocker WINDOWMANAGER DOCKERIMAGE  IMAGECOMMAND  ARGS       WINDOWMANAGER     host window manager for use with single GUI applications                      To run without window manager from host  use       DOCKERIMAGE       docker image containing GUI applications or a desktop   IMAGECOMMAND      command to run in image   Windowmanager   1   amp  amp  shift Dockerimage         Container user Useruid   id -u  Usergid   id -g  Username    id -un       Useruid     0     amp  amp  Useruid 1000  amp  amp  Usergid 1000  amp  amp  Username  user Useruid     Find free display number for   Newdisplaynumber 1   Newdisplaynumber  lt   100   Newdisplaynumber       do     -e  tmp  X11-unix X Newdisplaynumber      break done Newxsocket  tmp  X11-unix X Newdisplaynumber    cache folder and files Cachefolder  tmp Xephyrdocker X Newdisplaynumber   -e   Cachefolder     amp  amp  rm -R   Cachefolder  mkdir -p  Cachefolder Xclientcookie  Cachefolder Xcookie client Xservercookie  Cachefolder Xcookie server Xinitrc  Cachefolder xinitrc Etcpasswd  Cachefolder passwd    command to run docker   --rm                               created container will be discarded    -e DISPLAY  Newdisplay             set environment variable to new display   -e XAUTHORITY  Xcookie             set environment variable XAUTHORITY to provided cookie   -v  Xclientcookie  Xcookie ro      provide cookie file to container   -v  NewXsocket  NewXsocket ro      Share new X socket of Xephyr   --user  Useruid  Usergid           Security  avoid root in container   -v  Etcpasswd  etc passwd ro        etc passwd file with user entry   --group-add audio                  Allow access to  dev snd if shared with  --device  dev snd     --cap-drop ALL                     Security  disable needless capabilities   --security-opt no-new-privileges   Security  forbid new privileges Dockercommand  docker run --rm     -e DISPLAY   Newdisplaynumber     -e XAUTHORITY  Xcookie     -v  Xclientcookie  Xcookie ro     -v  Newxsocket  Newxsocket rw     --user  Useruid  Usergid     -v  Etcpasswd  etc passwd ro     --group-add audio     --env HOME  tmp     --cap-drop ALL     --security-opt no-new-privileges       command -v docker-init  gt  dev null  amp  amp  echo --init       Dockerimage   echo  docker command    Dockercommand      command to run Xorg or Xephyr    usr bin Xephyr                an absolute path to X server executable must be given for xinit     Newdisplaynumber             first argument has to be new display   -auth  Xservercookie           path to cookie file for X server  Must be different from cookie file of client  not sure why   -extension MIT-SHM             disable MIT-SHM to avoid rendering glitches and bad RAM access    instead of - enables it    -nolisten tcp                  disable tcp connections for security reasons   -retro                         nice retro look Xcommand   usr bin Xephyr   Newdisplaynumber     -auth  Xservercookie     -extension MIT-SHM     -nolisten tcp     -screen 1000x750x24     -retro   echo  X server command   Xcommand      create  etc passwd with unprivileged user echo  root x 0 0 root  root  bin sh   gt  Etcpasswd echo   Username x  Useruid  Usergid  Username     tmp  bin sh   gt  gt   Etcpasswd    create xinitrc   echo      bin bash     echo    set environment variables to new display and new cookie    echo  export DISPLAY   Newdisplaynumber    echo  export XAUTHORITY  Xclientcookie     echo    same keyboard layout as on host    echo  echo    setxkbmap -display  DISPLAY -print     xkbcomp -   Newdisplaynumber     echo    create new XAUTHORITY cookie file     echo    gt   Xclientcookie    echo  xauth add   Newdisplaynumber     mcookie     echo    create prepared cookie with localhost identification disabled by ffff     echo    needed if X socket is shared instead connecting over tcp  ffff means  familiy wild     echo  Cookie   xauth nlist     Newdisplaynumber   sed -e  s       ffff        echo  echo  Cookie   xauth -f   Xclientcookie  nmerge -    echo  cp  Xclientcookie  Xservercookie    echo  chmod 644  Xclientcookie     echo    run window manager in Xephyr    echo  Windowmanager   amp  Windowmanagerpid        echo    show docker log    echo  tail --retry -n  1 -F   Dockerlogfile  2 gt  dev null  amp  Tailpid        echo    run docker    echo   Dockercommand     gt   Xinitrc  xinit   Xinitrc --  Xcommand rm -Rf  Cachefolder   This script is maintained at x11docker wiki  A more advanced script is x11docker that also supports features like GPU acceleration  webcam and printer sharing and so on

User · Answer

This is not lightweight but is a nice solution that gives docker feature parity with full desktop virtualization  Both Xfce4 or IceWM for Ubuntu and CentOS work  and the noVNC option makes for an easy access through a browser   https   github com ConSol docker-headless-vnc-container  It runs noVNC as well as tigerVNC s vncserver  Then it calls startx for given Window Manager  In addition  libnss wrapper so is used to emulate password management for the users

[x11] Can you run GUI applications in a Docker container?

Examples related to x11

Examples related to sandbox

Examples related to docker

Examples related to vnc