Details of the Docker directory mount method summary

When the Docker container is started, if you want to mount a directory of the host, you can specify it with the -v parameter.

For example, if I want to launch an centos container, the host's /test directory will mount to the container's /soft directory, which can be specified by:

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

This will automatically create a directory for /soft within the container when it starts. In this way, we can make one point clear: in the -v parameter, the directory before the colon ":" is the host directory, and the directory behind it is the directory inside the container.

It may seem simple, but it's not. Let's verify 1:

1. The container directory must not 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'.

Report an error directly, indicating that soft is not an absolute path. The so-called absolute path must start with the slash "/" below.

2. The host directory is automatically generated if it does not exist

If the /test directory exists on the host, remove 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

Looking at the host, I found a new /test directory

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

3. What if the directory of the host is a relative path?

This time, let's change the directory name to test1

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

Then go to the host machine to check whether there is a new /test1 directory, but the result is no. Is it because I used a relative path, so the generated test1 directory is in the current directory, but it still does not exist? Where is the /soft directory in the container? We can get the answer to this question by looking at part 1 of the container "Mounts" with the docker inspect command.

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

You can see that the container/soft directory is mounted on host/var/lib/docker/volumes/test1 / _data directory

Originally, the so-called relative path is/var lib/docker/volumes /, has nothing to do with the host machine in the current directory.

4. If only -v specifies 1 directory, how does this correspond?

Start 1 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
    }
  ],

As you can see, it is similar to the result in 3, except that instead of the relative path directory name, it is a randomly generated directory name.

5. If the directory's owner and group are modified in the container, will the corresponding hardpoints be modified?

Start by opening a container and viewing the properties of the /soft directory inside 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 host /test directory

[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'.

0

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

[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'.

1

Let's look at the host /test directory and see if the genus and genus groups will change.

[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'.

2

It turned into mycat...

It turns out that this is related to UID, which is an integer that the system USES internally to identify the user. In the 1 case, it corresponds to the username 11.

First check what UID corresponds to 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 corresponding user of 1000 in the host?

[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'.

4

As you can see, the user of UID 1000 in the host is mycat.

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

In this case, there are two main validations: 1. The host directory is specified, i.e. -v /test:/soft. 2. No host directory is specified, i.e. -v /soft

Case 1:

[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'.

5

As you can see, the new mount directory will not disappear even if the container is destroyed. Step 1 also verifies that if the host directory's genus and genus groups change, the host directory's genus and genus groups will not revert to their pre-mount state after container destruction.

2 case, through the above validation know, if you don't specify a host machine, the container will be in the/var lib/docker volumes/random configuration a directory, then we will look at this case container destruction leads to corresponding directory delete

Start the container first

[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'.

6

View the mount directory generated by the container on the host via the docker inspect command

[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'.

7

Corresponding/var lib/docker/volumes/b53164cb1c9f1917788638692fb22ad11994cf1fbbc2461b6c390cd3e10ea301 / _data directory

Destroy the container to 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

The directory was found to still exist, even after the docker service was restarted

[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'.

9

7. After mounting the host's existing directory, operate on it in the container and declare "Permission denied".

It can be solved in two ways:

1 > Close the selinux.

Temporarily closed: # setenforce 0

Permanently closed: modify the /etc/sysconfig/selinux file to set the value of SELINUX to disabled.

2 > Start the container in a privileged manner

Specify the --privileged parameter

Such as:

# docker run -it --privileged=true -v /test:/soft centos /bin/bash