Sometimes you want to perform some operation on the volume mounted at /, but not in any volume mounted under it. Some commands (e.g. “find” and “rsync”) provide options to avoid recursing into lower filesystems, but others (e.g. “du”) don’t make it so easy. A simple technique for getting around this is to use a bind mount. For example, after mount --bind / /mnt the /mnt directory shows you a view of the same filesystem as /, except you will notice that directories like /mnt/proc and (assuming your user files are on a separate volume) /mnt/home are empty. Or, to be more precise, those directories are now showing their original contents, unobscured by any other filesystem mounted on top of them. An example use of this is, the root partition on a machine might be filling up, and I want to know why. To narrow down which directories are using the space, I try to do du -ks /*/ but this wants to scan /home/ as well, which on this machine is a separate volume and therefore just adds greatly to the time taken without telling me anything relevant. But with the bind mount, I can do du -ks /mnt/*/ and it will only check the root volume. Another use of this is, as I mentioned above, you can see what is originally in the directories being used for mounting other filesystems. For example, one machine might normally have a network volume from another server mounted on a directory into which it regularly saves files. For some reason the network link might go down, and during that interval it blithely continues saving files into the local directory where the network volume was mounted, rather than the network volume itself. After the network mount is restored, you will probably want to check what files were accidentally saved locally, and move them onto the network volume where they belong. A bind mount lets you do this without disrupting access to the network volume. Then when you are finished with the bind mount, you can get rid of it in the usual way: umount /mnt