Mount overview

– Volumes (the recommended way) are stored in the host filesystem which is managed by Docker (/var/lib/docker/volumes/ on Linux).
Non-Docker processes should not modify this part of the filesystem.

– Bind mounts may be stored anywhere on the host system.
Non-Docker processes on the Docker host or a Docker container can modify them at any time.

– tmpfs mounts are stored in the host system’s memory only, and are never written to the host system’s filesystem.

Mount Details

By default, volume and bind are in read-write (rw) mode : any changes of its content from the container are propagated back to the Docker host.
By setting the mode to read-only (ro) mode, the changes cannot be modified any longer from the container. Only host may change that.

Volume

Bind

The file or directory does not need to exist on the Docker host. It is created on demand if it does not yet exist.
The mount initial setup is always mounting FILE/FOLDER FROM HOST to CONTAINER FILE/FOLDER.
So at setup it overwrites always files/folders in the container. Note that a mount of a not existing directory on the host will create that on the host with the root ownership.

By mounting a file, changes from the host are not propagated on the fly. The container need to be restarted.
By mounting a directory, changes from the host are propagated on the fly. The container doesn’t need to be restarted.

Example of a bind of a directory in ro mode :
-v $PWD/prometheus-conf/:/etc/prometheus/:ro

tmpfs

todo

Mount Use case

Volume

todo

Bind

Owner/group matching

A common difficulty with bind mount is the matching between the user id/group id (here only the ids matter, names are not used when the container is started) on the host and the ids of user/group starting the container.
Indeed, the owner (and or the group) of the bound directories/files on the host have to match with the user/group starting the container. The user of the container may be set in the docker image. For example defining the USER jenkins instruction in the Dockerfile changes the current user. At the end of the image built, the last one used is which one that is the « user of the container ».
To change the user of the container, we use the -u flag of the docker run subcommand such as : docker run -u john:men to pass john as user and men as group.
Beware : passing a name for the user and the group doesn’t work only if the user is defined in the image.
As the matching matters only for ids and not names, we could so only pass them if the names don’t exit or don’t match in the image (while the ids have to exit in the image of course) :
docker run -u $(id -u john):$(id -g men).
To pass the current user/group :
docker run -u $(id -u):$(id -g).

tmpfs

todo