What is a “bind mount”? How do I make one? What is it good for?
I've been told to use a bind mount for something, but I don't understand what it is or how to use it.
A bind mount is an alternate view of a directory tree. Classically, mounting creates a view of a storage device as a directory tree. A bind mount instead takes an existing directory tree and replicates it under a different point. The directories and files in the bind mount are the same as the original. Any modification on one side is immediately reflected on the other side, since the two views show the same data.
For example, after issuing the Linux command-
mount --bind /some/where /else/where
/else/where have the same content, which is the content of
/else/where was not empty, its previous content is now hidden.)
Unlike a hard link or symbolic link, a bind mount doesn't affect what is stored on the filesystem. It's a property of the live system.
bindfs /some/where /else/where
/else/where a mount point under which the contents of
/some/where are visible.
Since bindfs is a separate filesystem, the files
/else/where/foo appear as different files to applications (the bindfs filesystem has its own
st_dev value). Any change on one side is “magically” reflected on the other side, but the fact that the files are the same is only apparent when one knows how bindfs operates.
Bindfs has no knowledge of mount points, so if there is a mount point under
/some/where, it appears as just another directory under
/else/where. Mounting or unmounting a filesystem underneath
/some/where appears under
/else/where as a change of the corresponding directory.
Bindfs can alter some of the file metadata: it can show fake permissions and ownership for files. See the manual for details, and see below for examples.
A bindfs filesystem can be mounted as a non-root user, you only need the privilege to mount FUSE filesystems. Depending on your distribution, this may require being in the
fuse group or be allowed to all users. To unmount a FUSE filesystem, use
fusermount -u instead of
fusermount -u /else/where
FreeBSD provides the
nullfs filesystem which creates an alternate view of a filesystem. The following two commands are equivalent:
mount -t nullfs /some/where /else/where
mount_nullfs /some/where /else/where
After issuing either command,
/else/where becomes a mount point at which the contents of
/some/where are visible.
Since nullfs is a separate filesystem, the files
/else/where/foo appear as different files to applications (the nullfs filesystem has its own
st_dev value). Any change on one side is “magically” reflected on the other side, but the fact that the files are the same is only apparent when one knows how nullfs operates.
Unlike the FUSE bindfs, which acts at the level of the directory tree, FreeBSD's nullfs acts deeper in the kernel, so mount points under
/else/where are not visible: only the tree that is part of the same mount point as
/some/where is reflected under
The nullfs filesystem may be usable under other BSD variants (OS X, OpenBSD, NetBSD) but it is not compiled as part of the default system.
Under Linux, bind mounts are available as a kernel feature. You can create one with the
mount command, by passing either the
--bind command line option or the
bind mount option. The following two commands are equivalent:
mount --bind /some/where /else/where
mount -o bind /some/where /else/where
Here, the “device”
/some/where is not a disk partition like in the case of an on-disk filesystem, but an existing directory. The mount point
/else/where must be an existing directory as usual. Note that no filesystem type is specified either way: making a bind mount doesn't involve a filesystem driver, it copies the kernel data structures from the original mount.
mount --bind also support mounting a non-directory onto a non-directory:
/some/where can be a regular file (in which case
/else/where needs to be a regular file too).
A Linux bind mount is mostly indistinguishable from the original. The command
df -T /else/where shows the same device and the same filesystem type as
df -T /some/where. The files
/else/where/foo are indistinguishable, as if they were hard links. It is possible to unmount
/some/where, in which case
/else/where remains mounted.
With older kernels (I don't know exactly when, I think until some 3.x), bind mounts were truly indistinguishable from the original. Recent kernels do track bind mounts and expose the information through <code/proc/PID/mountinfo, which allows
findmnt to indicate bind mount as such.
You can put bind mount entries in
/etc/fstab. Just include
rbind etc.) in the options, together with any other options you want. The “device” is the existing tree. The filesystem column can contain
bind (it's ignored, but using a filesystem name would be confusing). For example:
/some/where /readonly/view none bind,ro
If there are mount points under
/some/where, their contents are not visible under
/else/where. Instead of
bind, you can use
rbind, also replicate mount points underneath
/some/where. For example, if
/some/where/mnt is a mount point then
mount --rbind /some/where /else/where
is equivalent to
mount --bind /some/where /else/where
mount --bind /some/where/mnt /else/where/mnt
In addition, Linux allows mounts to be declared as shared, slave, private or unbindable. This affects whether that mount operation is reflected under a bind mount that replicates the mount point. For more details, see the kernel documentation.
Linux also provides a way to move mounts: where
--move moves a mount point.
It is possible to have different mount options in two bind-mounted directories. There is a quirk, however: making the bind mount and setting the mount options cannot be done atomically, they have to be two successive operations. (Older kernels did not allow this.) For example, the following commands create a read-only view, but there is a small window of time during which
/else/where is read-write:
mount --bind /some/where /else/where
mount -o remount,ro,bind /else/where
If your system doesn't support FUSE, a classical trick to achieve the same effect is to run an NFS server, make it export the files you want to expose (allowing access to
localhost) and mount them on the same machine. This has a significant overhead in terms of memory and performance, so bind mounts have a definite advantage where available (which is on most Unix variants thanks to FUSE).
It can be useful to create a read-only view of a filesystem, either for security reasons or just as a layer of safety to ensure that you won't accidentally modify it.
bindfs -r /some/where /mnt/readonly
With Linux, the simple way:
mount --bind /some/where /mnt/readonly
mount -o remount,ro,bind /mnt/readonly
This leaves a short interval of time during which
/mnt/readonly is read-write. If this is a security concern, first create the bind mount in a directory that only root can access, make it read-only, then move it to a public mount point. In the snippet below, note that it's important that
/root/private (the directory above the mount point) is private; the original permissions on
/root/private/mnt are irrelevant since they are hidden behind the mount point.
mkdir -p /root/private/mnt
chmod 700 /root/private
mount --bind /some/where /root/private/mnt
mount -o remount,ro,bind /root/private/mnt
mount --move /root/private/mnt /mnt/readonly
Filesystems record users and groups by their numerical ID. Sometimes you end up with multiple systems which assign different user IDs to the same person. This is not a problem with network access, but it makes user IDs meaningless when you carry data from one system to another on a disk. Suppose that you have a disk created with a multi-user filesystem (e.g. ext4, btrfs, zfs, UFS, …) on a system where Alice has user ID 1000 and Bob has user ID 1001, and you want to make that disk accessible on a system where Alice has user ID 1001 and Bob has user ID 1000. If you mount the disk directly, Alice's files will appear as owned by Bob (because the user ID is 1001) and Bob's files will appear as owned by Alice (because the user ID is 1000).
You can use bindfs to remap user IDs. First mount the disk partition in a private directory, where only root can access it. Then create a bindfs view in a public area, with user ID and group ID remapping that swaps Alice's and Bob's user IDs and group IDs.
mkdir -p /root/private/alice_disk /media/alice_disk
chmod 700 /root/private
mount /dev/sdb1 /root/private/alice_disk
bindfs --map=1000/1001:1001/1000:@1000/1001:@1001/1000 /root/private/alice_disk /media/alice_disk
A chroot jail or container runs a process in a subtree of the system's directory tree. This can be useful to run a program with restricted access, e.g. run a network server with access to only its own files and the files that it serves, but not to other data stored on the same computer). A limitation of chroot is that the program is confined to one subtree: it can't access independent subtrees. Bind mounts allow grafting other subtrees onto that main tree. This makes them fundamental to most practical usage of containers under Linux.
For example, suppose that a machine runs a service
/usr/sbin/somethingd which should only have access to data under
/var/lib/something. The smallest directory tree that contains both of these files is the root. How can the service be confined? One possibility is to make hard links to all the files that the service needs (at least
/usr/sbin/somethingd and several shared libraries) under
/var/lib/something. But this is cumbersome (the hard links need to be updated whenever a file is upgraded), and doesn't work if
/usr are on different filesystems. A better solution is to create an ad hoc root and populate it with using mounts:
mkdir -p etc/something lib usr/lib usr/sbin var/lib/something
mount --bind /etc/something etc/something
mount --bind /lib lib
mount --bind /usr/lib usr/lib
mount --bind /usr/sbin usr/sbin
mount --bind /var/lib/something var/lib/something
mount -o remount,ro,bind etc/something
mount -o remount,ro,bind lib
mount -o remount,ro,bind usr/lib
mount -o remount,ro,bind usr/sbin
chroot . /usr/sbin/somethingd &
Linux's mount namespaces generalize chroots. Bind mounts are how namespaces can be populated in flexible ways. See Making a process read a different file for the same filename for an example.
Another use of chroots is to install a different distribution in a directory and run programs from it, even when they require files at hard-coded paths that are not present or have different content on the base system. This can be useful, for example, to install a 32-bit distribution on a 64-bit system that doesn't support mixed packages, to install older releases of a distribution or other distributions to test compatibility, to install a newer release to test the latest features while maintaining a stable base system, etc. See How do I run 32-bit programs on a 64-bit Debian/Ubuntu? for an example on Debian/Ubuntu.
Suppose that you have an installation of your distribution's latest packages under the directory
/f/unstable, where you run programs by switching to that directory with
chroot /f/unstable. To make home directories available from this installations, bind mount them into the chroot:
mount --bind /home /f/unstable/home
The program schroot does this automatically.
When you mount a filesystem on a directory, this hides what is behind the directory. The files in that directory become inaccessible until the directory is unmounted. Because BSD nullfs and Linux bind mounts operate at a lower level than the mount infrastructure, a nullfs mount or a bind mount of a filesystem exposes directories that were hidden behind submounts in the original.
For example, suppose that you have a tmpfs filesystem mounted at
/tmp. If there were files under
/tmp when the tmpfs filesystem was created, these files may still remain, effectively inaccessible but taking up disk space. Run
mount --bind / /mnt
mount -t nullfs / /mnt
(FreeBSD) to create a view of the root filesystem at
/mnt. The directory
/mnt/tmp is the one from the root filesystem.
Some NFS servers (such as the Linux kernel NFS server before NFSv4) always advertise the actual directory location when they export a directory. That is, when a client requests
server:/requested/location, the server serves the tree at the location
/requested/location. It is sometimes desirable to allow clients to request
/request/location but actually serve files under
/actual/location. If your NFS server doesn't support serving an alternate location, you can create a bind mount for the expected request, e.g.
/etc/exports and the following in
/actual/location /requested/location bind bind
Sometimes you'd like to make symbolic link to make a file
/some/where/is/my/file appear under
/else/where, but the application that uses
file expands symbolic links and rejects
/some/where/is/my/file. A bind mount can work around this: bind-mount
/else/where/is/my, and then
realpath will report
/else/where/is/my/file to be under
/else/where, not under
If you use bind mounts, you need to take care of applications that traverse the filesystem tree recursively, such as backups and indexing (e.g. to build a locate database).
Usually, bind mounts should be excluded from recursive directory traversals, so that each directory tree is only traversed once, at the original location. With bindfs and nullfs, configure the traversal tool to ignore these filesystem types, if possible. Linux bind mounts cannot be recognized as such: the new location is equivalent to the original. With Linux bind mounts, or with tools that can only exclude paths and not filesystem types, you need to exclude the mount points for the bind mounts.
Traversals that stop at filesystem boundaries (e.g.
du -x, …) will automatically stop when they encounter a bindfs or nullfs mount point, because that mount point is a different filesystem. With Linux bind mounts, the situation is a bit more complicated: there is a filesystem boundary only if the bind mount is grafting a different filesystem, not if it is grafting another part of the same filesystem.
Bind mounts provide a view of a directory tree at a different location. They expose the same files, possibly with different mount options and (with bindfs) different ownership and permissions. Filesystems that present an altered view of a directory tree are called overlay filesystems or stackable filesystems. There are many other overlay filesystems that perform more advanced transformations. Here are a few common ones. If your desired use case is not covered here, check the repository of FUSE filesystems.
clamfs — run files through a virus scanner when they are read
filterfs — hide parts of a filesystem
rofs — a read-only view. Similar to
bindfs -r, just a little more lightweight.
Union mounts — present multiple filesystems (called branches) under a single directory: if
bar then their union view contains both
bar. New files are written to a specific branch, or to a branch chosen according to more complex rules. There are several implementations of this concept, including:
I found the following explanation very helpful since it does not create the notion that it actually copies/duplicates data:
Bind mounts can be thought of as a sort of symbolic link at the filesystem level. Using
mount --bind, it is possible to create a second mount point for an existing filesystem, making that filesystem visible at a different spot in the namespace.
Bind mounts are thus useful for creating specific views of the filesystem namespace; one can, for example, create a bind mount which makes a piece of a filesystem visible within an environment which is otherwise closed off with