I. Introduction

DockerWhen the container starts, if you want to mount a directory of the host, you can -vspecify it with parameters.

For example, to start a centoscontainer, mount the /test directory of the host to the /soft directory of the container, which can be specified in the following ways:

docker run -it -v /test:/soft centos /bin/bash

In this way, after the container is started, the /soft directory will be automatically created in the container. In this way, we can make it clear that in the -v parameter, the directory before the colon “:” is the host directory, and the following directory is the directory in the container.

It seems simple, but it’s not. Let’s verify it:

2. The container directory cannot be a relative path

[root@localhost ~]# docker run -it -v /test:soft centos /bin/bash
invalid value "/test:soft" for flag -v: soft is not an absolute path
See 'docker run --help'.

An error is reported directly, indicating that soft is not an absolute path. The so-called absolute path must start with the following slash “/”.

3. If the host directory does not exist, it will be automatically generated

If the /test directory exists on the host, delete it first

[root@localhost ~]# rm -rf /test
[root@localhost ~]# ls /
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

start the container

[root@localhost ~]# docker run -it -v /test:/soft centos /bin/bash
[root@a487a3ca7997 /]# ls
bin  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  soft  srv  sys  tmp  usr  var

Check the host and find that a new /test directory has been added

[root@localhost ~]# ls /
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  test  tmp  usr  var

4. What if the host’s directory is a relative path?

This time, let’s try changing the directory name test1

docker run -it -v test1:/soft centos /bin/bash

Then go to the host to see if a new /test1 directory has been added. The result is not. Is it because I used a relative path, so the generated test1 directory is in the current directory, and it turns out that there is still no. Where is the /soft directory in the container mounted? We can get the answer to this question by looking at the “Mounts” part of the container with the docker inspect command.

"Mounts": [
    {
        "Name": "test1",
        "Source": "/var/lib/docker/volumes/test1/_data",
        "Destination": "/soft",
        "Driver": "local",
        "Mode": "z",
        "RW": true
    }
],

It can be seen that the /soft directory in the container is mounted on the /var/lib/docker/volumes/test1/_data directory on the host

It turns out that the so-called relative path refers to /var/lib/docker/volumes/, which has nothing to do with the current directory of the host.

5. If only -v specifies a directory, how does this correspond?

start a container

[root@localhost ~]# docker run -it -v /test2 centos /bin/bash
[root@ea24067bc902 /]# ls
bin  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  test2  tmp  usr  var

Also use the docker inspect command to view the mount directory of the host

"Mounts": [
     {
         "Name": "96256232eb74edb139d652746f0fe426e57fbacdf73376963e3acdb411b3d73a",
         "Source": "/var/lib/docker/volumes/96256232eb74edb139d652746f0fe426e57fbacdf73376963e3acdb411b3d73a/_data",
         "Destination": "/test2",
         "Driver": "local",
         "Mode": "",
         "RW": true
     }
 ],

It can be seen that it is similar to the result in 3, except that it is not a directory name of a relative path, but a randomly generated directory name.

6. If the owner and group of a directory are modified in the container, will the corresponding mount point be modified?

First open a container and view the properties of the /soft directory in the container

[root@localhost ~]# docker run -it -v /test:/soft centos /bin/bash
[root@b5ed8216401f /]# ll -d /soft/
drwxr-xr-x 2 root root 6 Sep 24 03:48 /soft/

View the properties of the /test directory in the host

[root@localhost ~]# ll -d /test/
drwxr-xr-x 2 root root 6 Sep 24 11:48 /test/

Create a new user in the container, modify the owner and group of /soft

[root@b5ed8216401f /]# useradd victor
[root@b5ed8216401f /]# chown -R victor.victor /soft/
[root@b5ed8216401f /]# ll -d /soft/
drwxr-xr-x 2 victor victor 6 Sep 24 03:48 /soft/

Let’s see if the owner and group of the /test directory in the host will change?

[root@localhost ~]# ll -d /test/
drwxr-xr-x 2 mycat mycat 6 Sep 24 11:48 /test/

Turned into mycat. . .

It turns out that this is related to UID. UID, that is, “user identification number”, is an integer, which is used internally by the system to identify users. In general, it corresponds to the user name one-to-one.

First, check the UID corresponding to the victor in the container.

[root@b5ed8216401f /]# cat /etc/passwd | grep victor
victor:x:1000:1000::/home/victor:/bin/bash

The UID of victor is 1000, so who is the user corresponding to 1000 in the host?

[root@localhost ~]# cat /etc/passwd |grep 1000
mycat:x:1000:1000::/home/mycat:/bin/bash

It can be seen that the user corresponding to UID 1000 in the host is mycat.

7. If the container is destroyed, will the newly created mount directory on the host disappear?

Here, two situations are mainly verified: 1. The host directory is specified, ie -v /test:/soft. 2. No host directory is specified, ie -v /soft

The first case:

[root@localhost ~]# rm -rf /test    --First delete the /test directory on the host
[root@localhost ~]# ls /    --As you can see, there is no /test directory on the host
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[root@localhost ~]# docker run -it --name=centos_test -v /test:/soft centos /bin/bash  --To start the container, I specified the name of the container with the --name parameter for ease of removal
[root@82ad7f3a779a /]# exit
exit
[root@localhost ~]# docker rm centos_test   --delete container
centos_test
[root@localhost ~]# ls /   --Found that the / test directory still exists
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  test  tmp  usr  var

It can be seen that even if the container is destroyed, the newly created mount directory will not disappear. It can be further verified that if the owner and group of the host directory are changed, after the container is destroyed, the owner and group of the host directory will not be restored to the state before mounting.

In the second case, through the above verification, we know that if the host’s directory is not specified, the container will randomly configure a directory in /var/lib/docker/volumes/, then we will see if the container destruction in this case will Causes the deletion of the corresponding directory

Start the container first

[root@localhost ~]# docker run -it --name=centos_test -v /soft centos /bin/bash
[root@6b75579ec934 /]# exit
exit

docker inspectView the mount directory generated by the container on the host through the command

"Mounts": [
    {
        "Name": "b53164cb1c9f1917788638692fb22ad11994cf1fbbc2461b6c390cd3e10ea301",
        "Source": "/var/lib/docker/volumes/b53164cb1c9f1917788638692fb22ad11994cf1fbbc2461b6c390cd3e10ea301/_data",
        "Destination": "/soft",
        "Driver": "local",
        "Mode": "",
        "RW": true
    }
],

corresponds to the /var/lib/docker/volumes/b53164cb1c9f1917788638692fb22ad11994cf1fbbc2461b6c390cd3e10ea301/_datadirectory

Destroy the container and see if the directory exists

[root@localhost ~]# docker rm centos_test
centos_test
[root@localhost ~]# ll /var/lib/docker/volumes/b53164cb1c9f1917788638692fb22ad11994cf1fbbc2461b6c390cd3e10ea301
total 0
drwxr-xr-x 2 root root 6 Sep 24 14:25 _data

It is found that the directory still exists, even if the docker service is restarted, the directory still exists

[root@localhost ~]# systemctl restart docker
[root@localhost ~]# ll /var/lib/docker/volumes/b53164cb1c9f1917788638692fb22ad11994cf1fbbc2461b6c390cd3e10ea301
total 0
drwxr-xr-x 2 root root 6 Sep 24 14:25 _data

8. After mounting the existing directory on the host, operate it in the container and report “Permission denied”.

It can be solved in two ways:

1. Close selinux.Temporarily closed:setenforce 0Permanently close: Modify the /etc/sysconfig/selinuxfile, set SELINUXthe value of disabled.
2. Start the container as privilegedSpecify --privilegedparameterslike:docker run -it --privileged=true -v /test:/soft centos /bin/bash