{
	"id": "27af4a26-bea4-4094-b888-97862840630e",
	"created_at": "2026-04-06T00:13:48.347395Z",
	"updated_at": "2026-04-10T03:21:53.06936Z",
	"deleted_at": null,
	"sha1_hash": "9d984a43982e41a41ec7b2e9ddf68a13f476f38a",
	"title": "Bind mounts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 89510,
	"plain_text": "Bind mounts\r\nBy Docker Inc\r\nPublished: 2026-03-23 · Archived: 2026-04-05 17:19:17 UTC\r\nWhen you use a bind mount, a file or directory on the host machine is mounted from the host into a container. By\r\ncontrast, when you use a volume, a new directory is created within Docker's storage directory on the host\r\nmachine. Docker creates and maintains this storage location, but containers access it directly using standard\r\nfilesystem operations.\r\nBind mounts are appropriate for the following types of use case:\r\nSharing source code or build artifacts between a development environment on the Docker host and a\r\ncontainer.\r\nWhen you want to create or generate files in a container and persist the files onto the host's filesystem.\r\nSharing configuration files from the host machine to containers. This is how Docker provides DNS\r\nresolution to containers by default, by mounting /etc/resolv.conf from the host machine into each\r\ncontainer.\r\nBind mounts are also available for builds: you can bind mount source code from the host into the build container\r\nto test, lint, or compile a project.\r\nIf you bind mount file or directory into a directory in the container in which files or directories exist, the pre-existing files are obscured by the mount. This is similar to if you were to save files into /mnt on a Linux host,\r\nand then mounted a USB drive into /mnt . The contents of /mnt would be obscured by the contents of the USB\r\ndrive until the USB drive was unmounted.\r\nWith containers, there's no straightforward way of removing a mount to reveal the obscured files again. Your best\r\noption is to recreate the container without the mount.\r\nBind mounts have write access to files on the host by default.\r\nOne side effect of using bind mounts is that you can change the host filesystem via processes running in a\r\ncontainer, including creating, modifying, or deleting important system files or directories. This capability\r\ncan have security implications. For example, it may affect non-Docker processes on the host system.\r\nYou can use the readonly or ro option to prevent the container from writing to the mount.\r\nBind mounts are created to the Docker daemon host, not the client.\r\nIf you're using a remote Docker daemon, you can't create a bind mount to access files on the client machine\r\nin a container.\r\nhttps://docs.docker.com/storage/bind-mounts/\r\nPage 1 of 6\n\nFor Docker Desktop, the daemon runs inside a Linux VM, not directly on the native host. Docker Desktop\r\nhas built-in mechanisms that transparently handle bind mounts, allowing you to share native host\r\nfilesystem paths with containers running in the virtual machine.\r\nContainers with bind mounts are strongly tied to the host.\r\nBind mounts rely on the host machine's filesystem having a specific directory structure available. This\r\nreliance means that containers with bind mounts may fail if run on a different host without the same\r\ndirectory structure.\r\nTo create a bind mount, you can use either the --mount or --volume flag.\r\nIn general, --mount is preferred. The main difference is that the --mount flag is more explicit and supports all\r\nthe available options.\r\nIf you use --volume to bind-mount a file or directory that does not yet exist on the Docker host, Docker\r\nautomatically creates the directory on the host for you. It's always created as a directory.\r\n--mount does not automatically create a directory if the specified mount path does not exist on the host. Instead,\r\nit produces an error:\r\nOptions for --mount\r\nThe --mount flag consists of multiple key-value pairs, separated by commas and each consisting of a \u003ckey\u003e=\r\n\u003cvalue\u003e tuple. The order of the keys isn't significant.\r\nValid options for --mount type=bind include:\r\nOption Description\r\nsource , src\r\nThe location of the file or directory on the host. This can be an absolute or\r\nrelative path.\r\ndestination , dst ,\r\ntarget\r\nThe path where the file or directory is mounted in the container. Must be an\r\nabsolute path.\r\nreadonly , ro\r\nIf present, causes the bind mount to be mounted into the container as read-only.\r\nbind-propagation If present, changes the bind propagation.\r\nOptions for --volume\r\nThe --volume or -v flag consists of three fields, separated by colon characters ( : ). The fields must be in the\r\ncorrect order.\r\nThe first field is the path on the host to bind mount into the container. The second field is the path where the file or\r\ndirectory is mounted in the container.\r\nhttps://docs.docker.com/storage/bind-mounts/\r\nPage 2 of 6\n\nThe third field is optional, and is a comma-separated list of options. Valid options for --volume with a bind\r\nmount include:\r\nOption Description\r\nreadonly , ro If present, causes the bind mount to be mounted into the container as read-only.\r\nz , Z Configures SELinux labeling. See Configure the SELinux label\r\nrprivate (default) Sets bind propagation to rprivate for this mount. See Configure bind propagation.\r\nprivate Sets bind propagation to private for this mount. See Configure bind propagation.\r\nrshared Sets bind propagation to rshared for this mount. See Configure bind propagation.\r\nshared Sets bind propagation to shared for this mount. See Configure bind propagation.\r\nrslave Sets bind propagation to rslave for this mount. See Configure bind propagation.\r\nslave Sets bind propagation to slave for this mount. See Configure bind propagation.\r\nConsider a case where you have a directory source and that when you build the source code, the artifacts are\r\nsaved into another directory, source/target/ . You want the artifacts to be available to the container at /app/ ,\r\nand you want the container to get access to a new build each time you build the source on your development host.\r\nUse the following command to bind-mount the target/ directory into your container at /app/ . Run the\r\ncommand from within the source directory. The $(pwd) sub-command expands to the current working\r\ndirectory on Linux or macOS hosts. If you're on Windows, see also Path conversions on Windows.\r\nThe following --mount and -v examples produce the same result. You can't run them both unless you remove\r\nthe devtest container after running the first one.\r\nUse docker inspect devtest to verify that the bind mount was created correctly. Look for the Mounts section:\r\nThis shows that the mount is a bind mount, it shows the correct source and destination, it shows that the mount\r\nis read-write, and that the propagation is set to rprivate .\r\nStop and remove the container:\r\nMount into a non-empty directory on the container\r\nIf you bind-mount a directory into a non-empty directory on the container, the directory's existing contents are\r\nobscured by the bind mount. This can be beneficial, such as when you want to test a new version of your\r\napplication without building a new image. However, it can also be surprising and this behavior differs from that of\r\nvolumes.\r\nThis example is contrived to be extreme, but replaces the contents of the container's /usr/ directory with the\r\n/tmp/ directory on the host machine. In most cases, this would result in a non-functioning container.\r\nhttps://docs.docker.com/storage/bind-mounts/\r\nPage 3 of 6\n\nThe --mount and -v examples have the same end result.\r\nThe container is created but does not start. Remove it:\r\nFor some development applications, the container needs to write into the bind mount, so changes are propagated\r\nback to the Docker host. At other times, the container only needs read access.\r\nThis example modifies the previous one, but mounts the directory as a read-only bind mount, by adding ro to\r\nthe (empty by default) list of options, after the mount point within the container. Where multiple options are\r\npresent, separate them by commas.\r\nThe --mount and -v examples have the same result.\r\nUse docker inspect devtest to verify that the bind mount was created correctly. Look for the Mounts section:\r\nStop and remove the container:\r\nWhen you bind mount a path that itself contains mounts, those submounts are also included in the bind mount by\r\ndefault. This behavior is configurable, using the bind-recursive option for --mount . This option is only\r\nsupported with the --mount flag, not with -v or --volume .\r\nIf the bind mount is read-only, the Docker Engine makes a best-effort attempt at making the submounts read-only\r\nas well. This is referred to as recursive read-only mounts. Recursive read-only mounts require Linux kernel\r\nversion 5.12 or later. If you're running an older kernel version, submounts are automatically mounted as read-write\r\nby default. Attempting to set submounts to be read-only on a kernel version earlier than 5.12, using the bind-recursive=readonly option, results in an error.\r\nSupported values for the bind-recursive option are:\r\nValue Description\r\nenabled\r\n(default)\r\nRead-only mounts are made recursively read-only if kernel is v5.12 or later. Otherwise,\r\nsubmounts are read-write.\r\ndisabled Submounts are ignored (not included in the bind mount).\r\nwritable Submounts are read-write.\r\nreadonly Submounts are read-only. Requires kernel v5.12 or later.\r\nBind propagation defaults to rprivate for both bind mounts and volumes. It is only configurable for bind\r\nmounts, and only on Linux host machines. Bind propagation is an advanced topic and many users never need to\r\nconfigure it.\r\nBind propagation refers to whether or not mounts created within a given bind-mount can be propagated to replicas\r\nof that mount. Consider a mount point /mnt , which is also mounted on /tmp . The propagation settings control\r\nwhether a mount on /tmp/a would also be available on /mnt/a . Each propagation setting has a recursive\r\nhttps://docs.docker.com/storage/bind-mounts/\r\nPage 4 of 6\n\ncounterpoint. In the case of recursion, consider that /tmp/a is also mounted as /foo . The propagation settings\r\ncontrol whether /mnt/a and/or /tmp/a would exist.\r\nMount propagation doesn't work with Docker Desktop.\r\nPropagation\r\nsetting\r\nDescription\r\nshared\r\nSub-mounts of the original mount are exposed to replica mounts, and sub-mounts of\r\nreplica mounts are also propagated to the original mount.\r\nslave\r\nsimilar to a shared mount, but only in one direction. If the original mount exposes a sub-mount, the replica mount can see it. However, if the replica mount exposes a sub-mount,\r\nthe original mount cannot see it.\r\nprivate\r\nThe mount is private. Sub-mounts within it are not exposed to replica mounts, and sub-mounts of replica mounts are not exposed to the original mount.\r\nrshared\r\nThe same as shared, but the propagation also extends to and from mount points nested\r\nwithin any of the original or replica mount points.\r\nrslave\r\nThe same as slave, but the propagation also extends to and from mount points nested\r\nwithin any of the original or replica mount points.\r\nrprivate\r\nThe default. The same as private, meaning that no mount points anywhere within the\r\noriginal or replica mount points propagate in either direction.\r\nBefore you can set bind propagation on a mount point, the host filesystem needs to already support bind\r\npropagation.\r\nFor more information about bind propagation, see the Linux kernel documentation for shared subtree.\r\nThe following example mounts the target/ directory into the container twice, and the second mount sets both\r\nthe ro option and the rslave bind propagation option.\r\nThe --mount and -v examples have the same result.\r\nNow if you create /app/foo/ , /app2/foo/ also exists.\r\nIf you use SELinux, you can add the z or Z options to modify the SELinux label of the host file or directory\r\nbeing mounted into the container. This affects the file or directory on the host machine itself and can have\r\nconsequences outside of the scope of Docker.\r\nThe z option indicates that the bind mount content is shared among multiple containers.\r\nThe Z option indicates that the bind mount content is private and unshared.\r\nUse extreme caution with these options. Bind-mounting a system directory such as /home or /usr with the Z\r\noption renders your host machine inoperable and you may need to relabel the host machine files by hand.\r\nhttps://docs.docker.com/storage/bind-mounts/\r\nPage 5 of 6\n\nWhen using bind mounts with services, SELinux labels ( :Z and :z ), as well as :ro are ignored.\r\nSee moby/moby #32579 for details.\r\nThis example sets the z option to specify that multiple containers can share the bind mount's contents:\r\nIt is not possible to modify the SELinux label using the --mount flag.\r\nA single Docker Compose service with a bind mount looks like this:\r\nFor more information about using volumes of the bind type with Compose, see Compose reference on the\r\nvolumes top-level element. and Compose reference on the volume attribute.\r\nLearn about volumes.\r\nLearn about tmpfs mounts.\r\nLearn about storage drivers.\r\nSource: https://docs.docker.com/storage/bind-mounts/\r\nhttps://docs.docker.com/storage/bind-mounts/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.docker.com/storage/bind-mounts/"
	],
	"report_names": [
		"bind-mounts"
	],
	"threat_actors": [],
	"ts_created_at": 1775434428,
	"ts_updated_at": 1775791313,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9d984a43982e41a41ec7b2e9ddf68a13f476f38a.pdf",
		"text": "https://archive.orkl.eu/9d984a43982e41a41ec7b2e9ddf68a13f476f38a.txt",
		"img": "https://archive.orkl.eu/9d984a43982e41a41ec7b2e9ddf68a13f476f38a.jpg"
	}
}