Recently we did a quick dive into Bind Mounts on Linux (How to Use Bind Mounts on Linux). But did not touch much on how to safely remove them. This is that story. Bind mounts are extremely useful in Linux, especially when working with Docker containers, storage layouts, and homelabs. However, removing them can be confusing because a bind mount does not create a copy of your data. A bind mount simply exposes one directory through another path. Both paths point to the exact same files. This means deleting a file through either path deletes the same file.

The Problem With Removing a Bind Mount

A common mistake is assuming that removing the entry from /etc/fstab immediately removes the mount, after running sudo mount -a. It does not. I have seen people lose their data by doing just that and then deleting files from the "source" directory, thinking they were safe because the bind mount was removed. (No, really, other people, I swear I didn't do it. It was a friend of a friend.) So... The mount -a command only mounts entries from /etc/fstab. It does not unmount existing mounts that are already active. For example, after commenting out a bind mount in /etc/fstab:
sudo mount -a
the existing bind mount may still be active.

Find the Actual Mount Point

The first step is finding where Linux actually mounted the directory - findmnt You can also inspect the kernel mount table directly: grep downloads /proc/self/mountinfo In my case, I expected the bind mount to be on: /mnt/DockerStorage/nvme-downloads but the kernel showed:
134 130 259:1 /nvme-downloads /mnt/EirStorage/downloads rw,relatime shared:96 - ext4 /dev/nvme0n1p1 rw
The important part is the mount target:
/mnt/EirStorage/downloads
That is the path that must be unmounted as this is my target directory, as also shown above source /nvme-downloads to /mnt/EirStorage/downloads.

Unmount the Bind Mount

Use umount against the actual mount point:
sudo umount /mnt/EirStorage/downloads
If Linux reports that the target is busy, something is still using the directory. Find what is holding it open:
sudo fuser -vm /mnt/EirStorage/downloads
For Docker hosts, containers are often the reason. Stop the relevant container(s), then retry the unmount. If you are sure nothing important is using the directory, a lazy unmount can detach it:
sudo umount -l /mnt/EirStorage/downloads

Verify That the Bind Mount Is Gone

After unmounting, verify that the mount no longer exists:
findmnt /mnt/EirStorage/downloads
No output means there is no active mount there.

Verify That Your Directories Are Independent

The easiest way to confirm that two directories are no longer the same bind-mounted location is checking their inode numbers.
ls -ldi /mnt/EirStorage/downloads
ls -ldi /mnt/DockerStorage/nvme-downloads
Before removing the bind mount, both paths pointed to the same inode:
45481985 drwxr-xr-x /mnt/EirStorage/downloads
45481985 drwxr-xr-x /mnt/DockerStorage/nvme-downloads
After removing the bind mount, they became separate directories:
36700161 drwxrwxr-x /mnt/EirStorage/downloads
45481985 drwxr-xr-x /mnt/DockerStorage/nvme-downloads
Different inode numbers confirm that they are no longer the same directory.

Remember: Bind Mounts Are Not Mirrors

A bind mount does not synchronize two directories and it does not copy files.
  • Changes made through either path affect the same files.
  • Deleting a file through either path deletes the same file.
  • Removing the bind mount does not copy data back.
  • The data remains where it physically exists.

Check Your /etc/fstab Direction

A final thing to verify is that your bind mount direction is correct. The syntax is:
source target none bind 0 0
For example:
/mnt/DockerStorage/nvme-downloads /mnt/EirStorage/downloads none bind 0 0
means:
  • Source: /mnt/DockerStorage/nvme-downloads
  • Target: /mnt/EirStorage/downloads
Always remember: You unmount the target, not the source.