What is a bind mount?
What is a bind mount?
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
the directories /some/where
and /else/where
have the same content, which is the content of /some/where
. (If /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.
How do I create a bind mount?
bindfs
The bindfs
filesystem is a FUSE filesystem which creates a view of a directory tree. For example, the command
bindfs /some/where /else/where
makes /else/where
a mount point under which the contents of /some/where
are visible.
Since bindfs is a separate filesystem, the files /some/where/foo
and /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 umount
, e.g.
fusermount -u /else/where
nullfs
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 /some/where/foo
and /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 /else/where
.
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.
Linux bind mount
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 /some/where/foo
and /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 bind
(or rbind
etc.) in the options, together with any other options you want. The “device” is the existing tree. The filesystem column can contain none
or 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 --bind
copies, --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
I can't get bind mounts to work!
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).
Use cases
Read-only view
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.
With bindfs:
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
Remapping users and groups
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
See How does one permissibly access files on non-booted system's user's home folder? and mount --bind other user as myself another examples.
Mounting in a jail or container
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 /var/lib/something
and /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.
Running a different distribution
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.
Accessing files hidden behind a mount point
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
(Linux) or
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.
NFS exports at different paths
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.
/requested/location *.localdomain(rw,async)
in /etc/exports
and the following in /etc/fstab
:
/actual/location /requested/location bind bind
A substitute for symbolic links
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 /some/where/is/my
to /else/where/is/my
, and then realpath
will report /else/where/is/my/file
to be under /else/where
, not under /some/where
.
Side effects of bind mounts
Recursive directory traversals
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. find -xdev
, rsync -x
, 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.
Going beyond bind mounts
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.
- loggedfs — log all filesystem access for debugging or monitoring purposes (configuration file syntax, Is it possible to find out what program or script created a given file?, List the files accessed by a program)
Filter visible files
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
tree1
containsfoo
andtree2
containsbar
then their union view contains bothfoo
andbar
. 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:- aufs — Linux kernel implementation, but rejected upstream many times
- funionfs — FUSE implementation
- mhddfs — FUSE, write files to a branch based on free space
- overlay — Linux kernel implementation, merged upstream in Linux v3.18
- unionfs-fuse — FUSE, with caching and copy-on-write features
Modify file names and metadata
- ciopfs — case-insensitive filenames (can be useful to mount Windows filesystems)
- convmvfs — convert filenames between character sets (example)
- posixovl — store Unix filenames and other metadata (permissions, ownership, …) on more restricted filesystems such as VFAT (example)
View altered file contents
- avfs — for each archive file, present a directory with the content of the archive (example, more examples). There are also many FUSE filesystems that expose specific archives as directories.
- fuseflt — run files through a pipeline when reading them, e.g. to recode text files or media files (example)
- lzopfs — transparent decompression of compressed files
- mp3fs — transcode FLAC files to MP3 when they are read (example)
- scriptfs — execute scripts to serve content (a sort of local CGI) (example)
Modify the way content is stored
- chironfs — replicate files onto multiple underlying storage (RAID-1 at the directory tree level)
- copyfs — keep copies of all versions of the files
- encfs — encrypt files
- pcachefs — on-disk cache layer for slow remote filesystems
- simplecowfs — store changes via the provided view in memory, leaving the original files intact
- wayback — keep copies of all versions of the files