I installed Docker in my machine where I have Ubuntu OS.
When I run:
sudo docker run hello-world
All is ok, but I want to hide the sudo command to make the command shorter.
If I write the command without sudo
docker run hello-world
That displays the following:
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.35/containers/create: dial unix /var/run/docker.sock: connect: permission denied. See 'docker run --help'.
The same happens when I try to run:
docker-compose up
How can I resolve this?
If you want to run docker as non-root user then you need to add it to the docker group.
Create the docker group if it does not exist
$ sudo groupadd docker
Add your user to the docker group.
$ sudo usermod -aG docker $USER
Log in to the new docker group (to avoid having to log out / log in again; but if not enough, try to reboot):
$ newgrp docker
Check if docker can be run without root
$ docker run hello-world
Reboot if still got error
$ reboot
Warning
The docker group grants privileges equivalent to the root user. For details on how this impacts security in your system, see Docker Daemon Attack Surface..
Taken from the docker official documentation:
manage-docker-as-a-non-root-user
After an upgrade I got the permission denied.
Doing the steps of 'mkb' post install steps don't have change anything because my user was already in the 'docker' group; I retry-it twice any way without success.
After an search hour this following solution finaly worked :
sudo chmod 666 /var/run/docker.sock
Solution came from Olshansk.
Look like the upgrade have recreate the socket without enough permission for the 'docker' group.
Problems
This hard chmod open security hole and after each reboot, this error start again and again and you have to re-execute the above command each time. I want a solution once and for all. For that you have two problems :
1) Problem with SystemD : The socket will be create only with owner 'root' and group 'root'.
You can check this first problem with this command :
ls -l /lib/systemd/system/docker.socket
If every this is good, you should see 'root/docker' not 'root/root'.
2 ) Problem with graphical Login : https://superuser.com/questions/1348196/why-my-linux-account-only-belongs-to-one-group
You can check this second problem with this command :
groups
If everything is correct you should see the docker group in the list.
If not try the command
sudo su $USER -c groups
if you see then the docker group it is because of the bug.
Solutions
If you manage to to get a workaround for the graphical login, this should do the job :
sudo chgrp docker /lib/systemd/system/docker.socket
sudo chmod g+w /lib/systemd/system/docker.socket
But If you can't manage this bug, a not so bad solution could be this :
sudo chgrp $USER /lib/systemd/system/docker.socket
sudo chmod g+w /lib/systemd/system/docker.socket
This work because you are in a graphical environnement and probably the only user on your computer.
In both case you need a reboot (or an sudo chmod 666 /var/run/docker.sock)
Add docker group
$ sudo groupadd docker
Add your current user to docker group
$ sudo usermod -aG docker $USER
Switch session to docker group
$ newgrp - docker
Run an example to test
$ docker run hello-world
Add current user to docker group
sudo usermod -aG docker $USER
Change the permissions of docker socket to be able to connect
to the docker daemon /var/run/docker.sock
sudo chmod 666 /var/run/docker.sock
I solve this error with the command :
$ sudo chmod 666 /var/run/docker.sock
It only requires the changes in permission of sock file.
sudo chmod 666 /var/run/docker.sock
this will work definitely.
If creating a docker group and adding your user to it doesn't work (the best solution, described in the previous answers), then this one is the second best alternative:
sudo chown $USER /var/run/docker.sock
What it does is changing the ownership of the docker.sock file to your user.
Note: It's a really bad practice to use chmod 666, because it gives permissions to practically everyone to access and modify the docker.sock file.
Fix Docker Issue: (Permission denied)
Create the docker group if it does not exist: sudo groupadd docker
See number of super users in the available system: grep -Po '^sudo.+:\K.*$' /etc/group
Export the user in linux command shell: export USER=demoUser
Add user to the docker group: sudo usermod -aG docker $USER
Run the following command/ Login or logout: newgrp docker
Check if docker runs ok or not: docker run hello-world
Reboot if you still get an error: reboot
If it does not work, run this command:
sudo chmod 660 /var/run/docker.sock
You can always try Manage Docker as a non-root user paragraph in the https://docs.docker.com/install/linux/linux-postinstall/ docs.
After doing this also if the problem persists then you can run the following command to solve it:
sudo chmod 666 /var/run/docker.sock
We always forget about ACLs . See setfacl.
sudo setfacl -m user:$USER:rw /var/run/docker.sock
To fix that issue, I searched where is my docker and docker-compose installed. In my case, docker was installed in /usr/bin/docker and docker-compose was installed in /usr/local/bin/docker-compose path. Then, I write this in my terminal:
To docker:
sudo chmod +x /usr/bin/docker
To docker-compose:
sudo chmod +x /usr/local/bin/docker-compose
Now I don't need write in my commands docker the word sudo
/***********************************************************************/
ERRATA:
The best solution of this issue was commented by #mkasberg. I quote comment:
That might work, you might run into issues down the road. Also, it's a security vulnerability. You'd be better off just adding yourself to the docker group, as the docs say. sudo groupadd docker, sudo usermod -aG docker $USER.
Docs: https://docs.docker.com/install/linux/linux-postinstall/
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/images/json: dial unix /var/run/docker.sock: connect: permission denied
sudo chmod 666 /var/run/docker.sock
This fix my problem.
ubuntu 21.04 systemd socket ownership
Let me preface, this was a perfectly suitable solution for me during local development and I got here searching for ubuntu docker permission error so i'll just leave this here.
I didn't own the unix socket, so I chowned it.
sudo chown $(whoami):$(whoami) /var/run/docker.sock
Another, more permanent solution for your dev environment, is to modify the user ownership of the unix socket creation. This will give your user the ownership, so it'll stick between restarts:
sudo nano /etc/systemd/system/sockets.target.wants/docker.socket
docker.socket:
[Unit]
Description=Docker Socket for the API
[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=YOUR_USERNAME_HERE
SocketGroup=docker
[Install]
WantedBy=sockets.target
Seriously guys. Do not add Docker in your groups or modifies the socket posix (without a hardening SELinux), it's a simple way to make a root privesc. Just add an alias in your .bashrc, it's simpler and safer as : alias dc='sudo docker'.
lightdm and kwallet ship with a bug that seems to not pass the supplementary groups at login. To solve this, I also, beside sudo usermod -aG docker $USER, had to comment out
auth optional pam_kwallet.so
auth optional pam_kwallet5.so
to
#auth optional pam_kwallet.so
#auth optional pam_kwallet5.so
in /etc/pam.d/lightdm before rebooting, for the docker-group to actually have effect.
bug: https://bugs.launchpad.net/lightdm/+bug/1781418 and here: https://bugzilla.redhat.com/show_bug.cgi?id=1581495
Rebooting the machine worked for me.
$ reboot
This work for me:
Get inside the container and modify the file's ACL
sudo usermod -aG docker $USER
sudo setfacl --modify user:$USER:rw /var/run/docker.sock
It's a better solution than use chmod.
use this command
sudo usermod -aG docker $USER
then restart your computer this worked for me.
you can follow these steps and this will work for you:
create a docker group sudo groupadd docker
add your user to this group sudo usermod -aG docker $USER
list the groups to make sure that docker group created successfully by running this command groups
run the following command also to change the session for docker group newgrp docker
change the group ownership for file docker.socksudo chown root:docker /var/run/docker.sock
change the ownership for .docker directory sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
finally sudo chmod g+rwx "$HOME/.docker" -R
After that test you can run docker ps -a
I ran into a similar problem as well, but where the container I wanted to create needed to mount /var/run/docker.sock as a volume (Portainer Agent), while running it all under a different namespace. Normally a container does not care about which namespace it is started in -- that is sort of the point -- but since access was made from a different namespace, this had to be circumvented.
Adding --userns=host to the run command for the container enabled it to use the attain the correct permissions.
Quite a specific use case, but after more research hours than I want to admit I just thought I should share it with the world if someone else ends up in this situation :)
i try this commend with sudo commend and it was ok.sudo docker pull hello-world or sudo docker run hello-world
In the Linux environment, after installing docker and docker-compose reboot is required for work docker better to avoid this issue.
$ sudo systemctl restart docker
It is definitely not the case the question was about, but as it is the first search result while googling the error message, I'll leave it here.
First of all, check if docker service is running using the following command:
systemctl status docker.service
If it is not running, try starting it:
sudo systemctl start docker.service
... and check the status again:
systemctl status docker.service
If it has not started, investigate the reason. Probably, you have modified a config file and made an error (like I did while modifying /etc/docker/daemon.json)
The Docker daemon binds to a Unix socket instead of a TCP port.
By default that Unix socket is owned by the user root and other users can only access it using sudo. The Docker daemon always runs as the root user.
If you don’t want to preface the docker command with sudo, create a Unix group called docker and add users to it. When the Docker daemon starts, it creates a Unix socket accessible by members of the docker group.
To create the docker group and add your user:
Create the docker group
sudo groupadd docker
Add your user to the docker group
sudo usermod -aG docker $USER
Log out and log back in so that your group membership is re-evaluated.
If testing on a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.
On a desktop Linux environment such as X Windows, log out of your session completely and then log back in.
On Linux, you can also run the following command to activate the changes to groups:
newgrp docker
Verify that you can run docker commands without sudo. The below command downloads a test image and runs it in a container. When the container runs, it prints an informational message and exits
docker run hello-world
If you initially ran Docker CLI commands using sudo before adding your user to the docker group, you may see the following error, which indicates that your ~/.docker/ directory was created with incorrect permissions due to the sudo commands.
WARNING: Error loading config file: /home/user/.docker/config.json -
stat /home/user/.docker/config.json: permission denied
To fix this problem, either remove the ~/.docker/ directory (it is recreated automatically, but any custom settings are lost), or change its ownership and permissions using the following commands:
sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
sudo chmod g+rwx "$HOME/.docker" -R
All other post installation steps for docker on linux can be found here https://docs.docker.com/engine/install/linux-postinstall/
The most straightforward solution is to type
sudo chmod 666 /var/run/docker.sock
every time you boot your machine. However, this method defeats any system security that may be in place and opens up the Docker socket to everybody. If this is acceptable to you -e.g.: the only user of your machine- then use it.
Nevertheless, it will be required every time you boot your machine, you can make it run with booting by adding
start on startup
task
exec chmod 666 /var/run/docker.sock
to the /etc/init/docker-chmod.conf file.
I tried all the described methods and nothing helped to solve the problem. The solution was to use the --use-drivers parameter when running selenoid and selenoid-ui. Below is the full listing of my Dockerfile.
FROM selenoid/chrome
USER root
RUN apt-get update
RUN apt-get -y install docker.io
RUN curl -s https://aerokube.com/cm/bash | bash
RUN ./cm selenoid start --vnc --use-drivers
RUN ./cm selenoid-ui start --use-drivers
EXPOSE 4444 8080
CMD ["-conf", "/etc/selenoid/browsers.json", "-video-output-dir", "/opt/selenoid/video/"]
In my case it was the process itself (CI server agent) that was trying to run a docker command wasn't able to run it, but when I tried to run same command from within the same user it worked.
Restarting the daemon that runs CI server agent solved the problem.
The reason why command wasn't working from within agent before is because the agent was running before I installed docker and granted docker group permissions, and agent process used cached old permissions and was failing. Restarting the process dropped the cache and make things work out.
As a shortest answer for linux user ->
Simply try any command as super user with "sudo"
Eg:- sudo docker-compose up
After Docker Installation on Centos. While running below command I got below error.
[centos#aiops-dev-cassandra3 ~]$ docker run hello-world
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.soc k/v1.40/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
Change Group and Permission for docker.socket
[centos#aiops-dev-cassandra3 ~]$ ls -l /lib/systemd/system/docker.socket
-rw-r--r--. 1 root root 197 Nov 13 07:25 /lib/systemd/system/docker.socket
[centos#aiops-dev-cassandra3 ~]$ sudo chgrp docker /lib/systemd/system/docker.socket
[centos#aiops-dev-cassandra3 ~]$ sudo chmod 666 /var/run/docker.sock
[centos#aiops-dev-cassandra3 ~]$ ls -lrth /var/run/docker.sock
srw-rw-rw-. 1 root docker 0 Nov 20 11:59 /var/run/docker.sock
[centos#aiops-dev-cassandra3 ~]$
Verify by using below docker command
[centos#aiops-dev-cassandra3 ~]$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:c3b4ada4687bbaa170745b3e4dd8ac3f194ca95b2d0518b417fb47e5879d9b5f
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/
[centos#aiops-dev-cassandra3 ~]$
After you installed docker, created 'docker' group and added user to it, edit docker service unit file:
sudo nano /usr/lib/systemd/system/docker.service
Add two lines into the section [Service]:
SupplementaryGroups=docker
ExecStartPost=/bin/chmod 666 /var/run/docker.sock
Save the file (Ctrl-X, y, Enter)
Run and enable the Docker service:
sudo systemctl daemon-reload
sudo systemctl start docker
sudo systemctl enable docker
How can you run GUI applications in a Linux 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?
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" > /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" >> /.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
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 - << __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
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
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 - < 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.
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>&1 > /dev/null &
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
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.
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" && shift
Dockerimage="$*"
# Container user
Useruid=$(id -u)
Usergid=$(id -g)
Username="$(id -un)"
[ "$Useruid" = "0" ] && Useruid=1000 && Usergid=1000 && Username="user$Useruid"
# Find free display number
for ((Newdisplaynumber=1 ; Newdisplaynumber <= 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" ] && 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 >/dev/null && 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" >$Etcpasswd
echo "$Username:x:$Useruid:$Usergid:$Username,,,:/tmp:/bin/sh" >> $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 ":> $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' & Windowmanagerpid=$!'
echo "# show docker log"
echo 'tail --retry -n +1 -F '$Dockerlogfile' 2>/dev/null & Tailpid=$!'
echo "# run docker"
echo "$Dockercommand"
} > $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.
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
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 <shared hex key>
The catch is that the cookie has to be added with xauth add inside the container:
touch ~/.Xauthority
xauth add containerhostname/unix:0 . <shared hex key>
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.
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.
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/
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
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.
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.
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 \
&& 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 \
&& 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 &
sleep 5
x11vnc -noxdamage -many -display :1 -rfbport 5901 -rfbauth ~/.x11vnc/passwd -bg
sleep 2
xfce4-session &
bash
# while true; do sleep 1000; done
Check the linked readme for build and run commands if you want/need.
Based on Jürgen Weigert's answer, I have some improvement:
docker build -t xeyes - << __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 && 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' < /etc/rc.local | sudo tee /etc/rc.local >/dev/null
sudo sed -i 's|\x00XAUTH_DIR=.*\x00\x00|\x00|' /etc/rc.local >/dev/null
tr '\000' '\n' < /etc/rc.local | sudo tee /etc/rc.local >/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' < ~/.profile | sudo tee ~/.profile >/dev/null
sed -i 's|\x00XAUTH_DIR=.*-\x00|\x00|' ~/.profile
tr '\000' '\n' < ~/.profile | sudo tee ~/.profile >/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 -" >> ~/.profile
Afterall, the container will automatically get the Xauthority file every time the system restart and user login.
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.
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
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
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 & home & 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.
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.
fcwu/docker-ubuntu-vnc-desktop (Ubuntu 18.04, 20.04)
https://github.com/fcwu/docker-ubuntu-vnc-desktop provides a convenient setup. That setup is not minimized. It would be good to minimize it. But I just don't have the time, and that one just works every time I try, so I tend to just use it. On the upside, because it is not minimized, it tends to test more complex programs you might actually to see that they are actually working through the infinitely many pitfalls of Docker. Also, since setups breaks on every guest/host update, a minimization would arguably only work for a limited period until you'd have to reminimize that project again.
To fire it up just run:
sudo docker run --name ubvnc -p 6080:80 -p 5900:5900 dorowu/ubuntu-desktop-lxde-vnc:focal
Then on host either:
visit: http://127.0.0.1:6080/#/ which runs a noVNC more limited JavaScript VNC client
run:
sudo apt-get install tigervnc-viewer
xtigervncviewer :5900
To go into fullscreen mode, hit F8 and click on menu entry, or just F8 followed by T: https://superuser.com/questions/285843/how-do-i-switch-in-out-of-fullscreen-mode-from-the-command-line-in-realvnc You might need to close and reopen the screen after that for the image to get larger.
I also tried vinagre, but it was much laggier when scrolling Firefox on YouTube.
Inside vinagre, you might want to go into full screen mode to be able to see the full desktop
To quit just kill docker on the terminal. And to restart the machine:
sudo docker start ubvnc
and then reconnect with VNC. Then to quit the machine:
sudo docker stop ubvnc
You have to wait a few seconds for the VNC server on the guest to start before you can connect.
Chromium inside the guest won't start from the menu. If you try to launch it from the command line it explains why:
Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
so just run it from the CLI with:
chromium-browser --no-sandbox
Firefox does not care however.
TODO: no audio. --device /dev/snd did not help:
How to play sound in a Docker container on Mac OS Yosemite
https://forums.docker.com/t/how-to-get-sound/36527
https://github.com/fcwu/docker-ubuntu-vnc-desktop/issues/49
EDIT: they added a section for it: https://github.com/fcwu/docker-ubuntu-vnc-desktop/tree/e4922ce92f945fc482994b7a0fd95ca5de7295b3#sound-preview-version-and-linux-only
See also:
How to open Ubuntu GUI inside a Docker image
Tested on:
Ubuntu 19.04 host, fcwu/docker-ubuntu-vnc-desktop, dorowu/ubuntu-desktop-lxde-vnc image id: 70516b87e92d.
Ubuntu 21.10 host, dorowu/ubuntu-desktop-lxde-vnc:focal (Ubuntu 20.04)
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
There're many good answers here on how to connect GUI app in docker container to X server running on host machine, or how to run virtual X server and connect to container using VNC to access it.
There's however another solution (which is quite useful for say kiosks or home theatres) - you can run X server inside docker container with video output to the monitor connected to your host machine.
First let's create a docker volume to store the X11 socket:
docker volume create --name xsocket
Now we can create an image with X Server:
FROM ubuntu
RUN apt-get update && \
DEBIAN_FRONTEND='noninteractive' apt-get install -y xorg
CMD /usr/bin/X :0 -nolisten tcp vt1
Let us build it and start it and store the X11 socket in xsocket docker volume:
docker build . -t docker-x-server:latest
docker run --privileged -v xsocket:/tmp/.X11-unix -d docker-x-server:latest
Now we can run a GUI application in another docker container (yay!) and point it to our X server using xsocket volume:
docker run --rm -it -e DISPLAY=:0 -v xsocket:/tmp/.X11-unix:ro stefanscherer/xeyes
If you need input (like keyboard) install xserver-xorg-input-evdev package and add -v /run/udev/data:/run/udev/data since there's no udev in containers by default.
You can even get rid of --privileged flag by granting SYS_TTY_CONFIG capability and binding some devices into container:
docker run --name docker-x-server --device=/dev/input --device=/dev/console --device=/dev/dri --device=/dev/fb0 --device=/dev/tty --device=/dev/tty1 --device=/dev/vga_arbiter --device=/dev/snd --device=/dev/psaux --cap-add=SYS_TTY_CONFIG -v xsocket:/tmp/.X11-unix -d docker-x-server:latest