I am very new to Unix/docker,
I have the following two outputs on the console,
admin#ansible:~/nachiket/workspace/docker-nachi-sample-app$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
admin#ansible:~/nachiket/workspace/docker-nachi-sample-app$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nachiketjoshi/python-log-generator latest ca675b7439ab About an hour ago 908MB
python 2.7 4ee4ea2f0113 3 weeks ago 908MB
can someone explain how the Unix user level is affecting my visibility to docker images...
It is because
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.
So, after installing docker to have the same access level on another user instead of root you need to perform:
sudo groupadd docker
sudo usermod -aG docker $USER
Then verify if it worked on docker uses:
docker run hello-world
If everything goes right try to execute docker images and see if it has the same access level, I've tested on CentOS and it worked
Reference: https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user
Related
I have Ubuntu 18.04. and after installing docker i added my user to docker group with the command
sudo usermod -aG docker ${USER}
and logged in
su - ${USER}
and if I check id, my user is added to docker group.
But when I reopen the terminal i cant do docker commands without sudo unless i explicitly do su ${USER}
also, I can't find docker group with the default user.
What am I missing here?
#larsks already replied to the main question in a comment, however I would like to elaborate on the implications of that change (adding your default user to the docker group).
Basically, the Docker daemon socket is owned by root:docker, so in order to use the Docker CLI commands, you need either to be in the docker group, or to prepend all docker commands by sudo.
As indicated in the documentation of Docker, it is risky to follow the first solution on your personal workstation, because this just amounts to providing the default user with root permissions without sudo-like password prompt protection. Indeed, users in the docker group are de facto root on the host. See for example this article and that one.
Instead, you may want to follow the second solution, which can be somewhat simplified by adding to your ~/.bashrc file an alias such as:
alias docker="sudo /usr/bin/docker"
Thus, docker run --rm -it debian will be automatically expanded to sudo /usr/bin/docker run --rm -it debian, thereby preserving sudo’s protection for your default user.
I've set up Docker to run as a non-root user. Now I can start my containers as an ordinary user and I feel more comfortable.
me#machine:~$ docker run -it -v ~/test:/test alpine:3.6 sh
/ # touch /test/test1
Meanwhile on the host:
me#machine:~$ ls -l ~/test/
total 0
-rw-r--r-- 1 root root 0 Jul 31 15:50 test1
Why do the files belong to root? How can I make them and all created files in the container belong to me?
Interesting fact: This happens on Debian Linux. Contrary, doing the same on a Mac, the created files would belong to me.
Mac OS Docker and Linux Docker have lot of changes in behavior. So ignore that part. Focus on the side of Linux.
What you did using https://docs.docker.com/engine/installation/linux/linux-postinstall/#manage-docker-as-a-non-root-user basically just means that a non-root user has access to the docker group. Through that docker group you are able to execute docker command. But docker daemon is still running as root user.
That you can confirm by running
ps aux | grep dockerd
And when you do a volume mapping, the directory gets created by docker, which eventually has root user permission. What you are looking for has been launched very recently as Docker user namespaces. Please read the details on below URL
https://success.docker.com/KBase/Introduction_to_User_Namespaces_in_Docker_Engine
This will guide you how to run your docker containers with a mapped user instead of root. In short create/update /etc/docker/daemon.json file to have below content
/etc/docker/daemon.json
{
"userns-remap": "<a non root user>"
}
And restart the docker service. Now your docker containers inside will think they have root privileges but they would run as a non-root user on host
I have a script that communicates over serial port (/dev/ttyUSB0). I want to run it from within a Docker image. However I don't seem to have permissions to do it from within the image. I follow these steps:
On my host, if I run ln -l /dev/ttyUSB0 I get:
crw-rw---- 1 root dialout 188, 0 jul 2 14:34 /dev/ttyUSB0
Good, it means that in order to read/write to it, I need to be either root, or part of the dialout group.
I become member of this group in my host:
$ sudo usermod -aG dialout $(whoami)
Then I log out and log in again to make this effective.
After that, I verify that I can communicate perfectly with /dev/ttyUSB0 from my host. However if I run the docker image:
docker run --user=1000:1000 --rm=true --tty=true --privileged=true --device=/dev/ttyUSB0 --volume=<my_dir>:<my_dir> --workdir=<my_dir> <my_docker_image> <my_script>
Then it complains:
can't open device "/dev/ttyUSB0": Permission denied
However if I use: --user=1000:20, then it works fine. The group 20 is the dialout group.
Now my question:
Why does Docker not understand that my user (1000) and group (1000) is part of the dialout group?
This was working when I used the old docker (apt-get install docker-io, docker-engine), but after updating to the new Docker CE this stopped working.
Setup:
Ubuntu 16.04.2 LTS Kernel 4.4.0-83-generic.
Docker version: Docker version 17.06.0-ce, build 02c1d87.
Thanks!
As stated in a comment, The solution was to pass --group-add=dialout to the docker run call. However, be aware that when using docker images that provides a way to specify the user and group using an environment variable (usually -e PUID=<UID> -e PGID=<GID>) it overwrites that setting.
I use following command to run a docker container, and map a directory from host(/root/database) to container(/tmp/install/database):
# docker run -it --name oracle_install -v /root/database:/tmp/install/database bofm/oracle12c:preinstall bash
But in container, I find I can't use ls to list contents in /tmp/install/database/ though I am root and have all privileges:
[root#77eb235aceac /]# cd /tmp/install/database/
[root#77eb235aceac database]# ls
ls: cannot open directory .: Permission denied
[root#77eb235aceac database]# id
uid=0(root) gid=0(root) groups=0(root)
[root#77eb235aceac database]# cd ..
[root#77eb235aceac install]# ls -alt
......
drwxr-xr-x. 7 root root 4096 Jul 7 2014 database
I check /root/database in host, and all things seem OK:
[root#localhost ~]# ls -lt
......
drwxr-xr-x. 7 root root 4096 Jul 7 2014 database
Why does docker container prompt "Permission denied"?
Update:
The root cause is related to SELinux. Actually, I met similar issue last year.
A permission denied within a container for a shared directory could be due to the fact that this shared directory is stored on a device. By default containers cannot access any devices. Adding the option $docker run --privileged allows the container to access all devices and performs Kernel calls. This is not considered as secure.
A cleaner way to share device is to use the option docker run --device=/dev/sdb (if /dev/sdb is the device you want to share).
From the man page:
--device=[]
Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm)
--privileged=true|false
Give extended privileges to this container. The default is false.
By default, Docker containers are “unprivileged” (=false) and cannot, for example, run a Docker daemon inside the Docker container. This is because by default a container is not allowed to access any devices. A “privileged” container is given access to all devices.
When the operator executes docker run --privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor to allow the container nearly all the same access to the host as processes running outside of a container on the host.
I had a similar issue when sharing an nfs mount point as a volume using docker-compose. I was able to resolve the issue with:
docker-compose up --force-recreate
Eventhough you found the issue, this may help someone else.
Another reason is a mismatch with the UID/GID. This often shows up as being able to modify a mount as root but not as the containers user
You can set the UID, so for an ubuntu container running as ubuntu you may need to append :uid=1000 (check with id -u) or set the UID locally depending on your use case.
uid=value and gid=value
Set the owner and group of the files in the filesystem (default: uid=gid=0)
There is a good blog about it here with this tmpfs example
docker run \
--rm \
--read-only \
--tmpfs=/var/run/prosody:uid=100 \
-it learning/tmpfs
http://www.dendeer.com/post/docker-tmpfs/
I got answer from a comment under: Why does docker container prompt Permission denied?
man docker-run gives the proper answer:
Labeling systems like SELinux require that proper labels are placed on volume content mounted into a container. Without a label, the security system might prevent the processes running
inside the container from using the content. By default, Docker does not change the labels set by the OS.
To change a label in the container context, you can add either of two suffixes :z or :Z to the volume mount. These suffixes tell Docker to relabel file objects on the shared volumes. The z option tells Docker that two containers share the volume content. As a result, Docker labels the content with a shared content label. Shared volume labels allow all containers to
read/write content. The Z option tells Docker to label the content with a private unshared label. Only the current container can use a private volume.
For example:
docker run -it --name oracle_install -v /root/database:/tmp/install/database:z ...
So I was trying to run a C file using Python os.system in the container but the I was getting the same error my fix was while creating the image add this line RUN chmod -R 777 app it worked for me
I am running the installation tutorial for Docker on Linux - Ubuntu 14.04
Going step by step through the tutorial, I get the following error message:
docker run hello-world
Post http:///var/run/docker.sock/v1.20/containers/create: dial unix /var/run/docker.sock: no such file or directory.
* Are you trying to connect to a TLS-enabled daemon without TLS?
* Is your docker daemon up and running?
The similar question docker error: /var/run/docker.sock: no such file or directory refers to boot2docker which I am not using
Had the same issue, solved:
docker-machine start default
eval "$(docker-machine env default)"
I got the same problem today. you just have to start the service.
sudo service docker start
It works on linux. I don't know if it works on mac
I had the same problem running docker on ubuntu 14.04.
Trying running Docker as root:
sudo docker run hello-world
Type in password when prompted.
Check the ownership of the file /var/run/docker.sock:
ls -l /var/run/docker.sock
srw-rw----. 1 root root 0 Nov 18 16:17 /var/run/docker.sock
Change the group settings to dockerroot:
sudo chown root:dockerroot /var/run/docker.sock
ls -l /var/run/docker.sock
srw-rw----. 1 root dockerroot 0 Nov 18 16:17 /var/run/docker.sock
Then it should work.
Both the solution here are tried and tested on linux only
Solution 1:
I was Having the same issue, Login with root privilege solved my problem
Solution 2:
The solution here works only with root user because root user has full access to linux socket similarly docker group has full access to linux socket.
if you want to run this with non root user you need to add user to docker group, you can do this with following command -
sudo usermod -aG docker $(whoami)
Now logout and login you should be able to work with non-root user :)
After getting stuck I turned off the computer and went on a road trip. One Monday I turned the computer on and docker run hello-world runs just as the tutorial indicated.
Had exactly the same problem on Windows 8.1
Answer was to open the Oracle VM Virtual Box, right click on the default instance and then click on "Show" icon. Then saw BootLocker logo.
Then back to the Docker Quickstarter "> whale" icon, double click and ascii docker appears.
In linux, after installation, though docker version was giving a proper output, docker run hello-world was not working because the service was not up.
I tried service docker restart in SLES 12 SP3 Linux machine. It worked. So probably your docker daemon needs a restart.
Try the same command service docker restart and it should work.
So, is the Docker daemon running? What troubleshooting did you already do?
The tutorial doesn't mention starting Docker or adding yourself to the docker group so that you can run Docker command without sudo (although, this should have been mentioned when you installed Docker). You need to do both of these things first.