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.
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.
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 PID/mountinfo, which allows
findmnt to indicate bind mount as such.
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 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.
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 /run/something cd /run/something 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
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.
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: