While no one likes opening up /etc/fstab and seeing 30 bind mounts, (a sure sign of an over caffeinated sysadmin), bind mounts can have their place in the world of system administration.
To put it in english, a bind mount is simply the process of mounting a specific directory from one path into another. And to describe it another way, it allows you to mount part of a filesystem to another location, and have it accessible from both locations.
Some common uses for bind mounts include:
– Providing access to log files from within a users home directory
– Providing access to files that reside outside a chroot
– Setting up NFSv4 /exports
– Setup a link that crosses filesystems, for example, a directory that resides on drive /dev/xvda1 to another drive on /dev/xvdb1
Basic bind mount example
Setting up a bind mount is simple. In the example below, we are going to bind mount our websites folder /var/www/vhosts/domain.com into our user’s folder: /home/bob
[root@server01 ~]# mkdir /home/bob/domain.com [root@server01 ~]# mount --bind /var/www/vhosts/domain.com /home/bob/domain.com
Then set the mount point to be persistent at boot:
[root@server01 ~]# vim /etc/fstab /var/www/vhosts/domain.com /home/bob/domain.com none bind 0 0
Read only bind mounts
Here is an example for setting up a ready only bind mount. In this example, we are going to bind mount our Apache logs in /var/log/httpd into our user’s folder: /home/bob, and only allow them read only permissions so they can troubleshoot their website:
[root@server01 ~]# mkdir /home/bob/logs [root@server01 ~]# mount --bind /var/log/httpd /home/bob/logs [root@server01 ~]# mount --bind -o remount,ro /home/bob/logs
Then set the mount point to be persistent at boot, retaining the read only permissions. This one is a bit more tricky as you cannot set the read only flag in /etc/fstab. Therefore, you need to for the remount command at startup by adding it into /etc/rc.local so it’ll run at boot time:
[root@server01 ~]# mkdir /home/bob/logs [root@server01 ~]# vim /etc/fstab /var/log/httpd /home/bob/logs none bind 0 0 [root@server01 ~]# chmod +x /etc/rc.local [root@server01 ~]# vim /etc/rc.local [root@server01 ~]# mount --bind -o remount,ro /home/bob/logs
Then consider rebooting your system to ensure the directory mounts properly in read only mode. You will know its successful when you cannot delete a file, or write a new file to that directory, even as the root user. For example:
[root@server01 ~]# touch /home/bob/logs/mylogfile touch: cannot touch `/home/bob/logs/mylogfile': Read-only file system [root@server01 ~]# rm -f /home/bob/logs/messages rm: cannot remove `/home/bob/logs/messages': Read-only file system
Looking at whats underneath a mount point
Sometimes a sysadmin may have setup a new drive as the existing one was full. Then they transferred over a large directory to the new disk and symlinked it back to the original location. However they forgot to cleanup the directory on the original disk, so how does one find whats using up all the space since du -sh will not be able to see whats in there?
In other words, if a filesystem is mounted on a directory that contains files, any files below the mount point are hidden by the mounted file system. So how can we easily see whats in that directory without un-mounting the filesystem?
You can use bind mounts to essentially ‘peek’ under a mount point. Lets say the mount point you wanted to peek under is in /home/mydirectory. You can peek under the /home/mydirectory mount point by:
[root@server01 ~]# mount --bind /home/mydirectory /tmp/mnt-peek
Now you can see what files are ‘hidden’ by checking in /tmp/mnt-new. Once your done, be sure to unmount it by:
[root@server01 ~]# umount /tmp/mnt-peek