Linux allows you to separate physical storage locations from logical application paths using filesystem mounts and bind mounts. This approach simplifies storage management and makes future migrations easier.

Instead of mounting an SSD directly at /mnt/backups, you can mount it at /mnt/ssd_1T and expose a specific directory through a bind mount at /mnt/backups.

This tutorial explains how to:

• Distinguish filesystem mounts from bind mounts.
• Configure persistent mounts using systemd.
• Separate physical storage from application paths.
• Verify mount points and disk usage.
• Troubleshoot common mounting issues, including target is busy errors.

Target architecture

/dev/sda1
    |
    v
/mnt/ssd_1T
    |
    v
/mnt/ssd_1T/backup_SNUBmonkey
    |
    | bind mount
    v
/mnt/backups

This structure provides a stable path for backup scripts, Docker volumes, and other applications, even if the underlying storage changes later.

1. Understanding filesystem mounts and bind mounts

Filesystem mount

A filesystem mount attaches a filesystem to a directory.

For example:

/dev/sda1 → /mnt/ssd_1T

Here, /dev/sda1 is the storage device, and /mnt/ssd_1T is the directory through which its filesystem is accessed.

Files stored under this mount point reside on the mounted filesystem.

Bind mount

A bind mount exposes an existing directory through another path without copying its contents or creating a separate filesystem.

For example:

/mnt/ssd_1T/backup_SNUBmonkey
                |
                v
          /mnt/backups

Both paths provide access to the same underlying files. Changes made through either path affect the same data.

A bind mount does not duplicate files or consume additional storage for their contents.

2. Why use a bind mount?

You could access the backup directory directly:

/mnt/ssd_1T/backup_SNUBmonkey

However, exposing it through /mnt/backups offers several practical advantages.

Stable application paths

Applications and scripts can consistently use:

/mnt/backups

If the storage later moves to a RAID array or another filesystem, you can change the mount configuration without updating every application that uses this path.

For example:

Current storage:
/mnt/ssd_1T/backup_SNUBmonkey

Future storage:
/mnt/raidZ2/backups

Stable application path:
/mnt/backups

Cleaner automation

A short, predictable path simplifies configuration in:

• rsync scripts
• Docker volume definitions
• Cron jobs
• Backup software
• Monitoring scripts

More controlled access

A bind mount makes a specific directory available at a separate path rather than requiring applications to use the storage mount's original directory structure.

Important: A bind mount is not, by itself, a security boundary. Access permissions and service isolation must still be configured appropriately.

3. Configure the physical SSD mount

First, identify the SSD's filesystem UUID and type:

$ sudo blkid

Locate the relevant device and note its UUID and filesystem type.

Create the mount-point directory:

$ sudo mkdir -p /mnt/ssd_1T

Create the systemd mount unit.

File: /etc/systemd/system/mnt-ssd_1T.mount

[Unit]
Description=Primary SSD Storage

[Mount]
What=UUID=c2f5xxxx-3xxx-4xxx-8xxx-11xxxxxxbxxx
Where=/mnt/ssd_1T
Type=ext4
Options=noatime

[Install]
WantedBy=multi-user.target

Replace the example UUID with the actual UUID of your SSD. Adjust Type=ext4 if the filesystem uses another type.

Understanding the configuration

• What= identifies the filesystem to mount. Using a UUID avoids relying on device names such as /dev/sda1, which can change.
• Where= specifies the mount point.
• Type= specifies the filesystem type.
• Options= defines mount options. Here, noatime reduces filesystem access-time updates.

The mount unit's filename must correspond to its Where= path. For /mnt/ssd_1T, the correct filename is mnt-ssd_1T.mount.

4. Create the backup directory

Start the SSD mount before creating the backup directory. Otherwise, if the SSD is not mounted, you could accidentally create the directory on the root filesystem.

Reload systemd and start the physical mount:

$ sudo systemctl daemon-reload
$ sudo systemctl start mnt-ssd_1T.mount

Verify that the SSD is mounted:

$ findmnt /mnt/ssd_1T

Once confirmed, create the backup directory on the SSD:

$ sudo mkdir -p /mnt/ssd_1T/backup_SNUBmonkey

Create the destination mount point:

$ sudo mkdir -p /mnt/backups

5. Configure the bind mount

Create the second systemd mount unit.

File: /etc/systemd/system/mnt-backups.mount

[Unit]
Description=Bind mount backup directory
Requires=mnt-ssd_1T.mount
After=mnt-ssd_1T.mount

[Mount]
What=/mnt/ssd_1T/backup_SNUBmonkey
Where=/mnt/backups
Type=none
Options=bind

[Install]
WantedBy=multi-user.target

Understanding the configuration

• Requires= pulls in the SSD mount unit as a dependency.
• After= ensures the SSD mount is ordered before the bind mount.
• What= specifies the source directory.
• Where= specifies the destination path.
• Type=none indicates that no filesystem type needs to be specified for this bind mount.
• Options=bind enables bind-mount behavior.

These dependencies ensure that systemd starts the SSD mount before the bind mount.

An alternative is to use RequiresMountsFor=/mnt/ssd_1T/backup_SNUBmonkey in the [Unit] section. This tells systemd to pull in the mounts required to access that path.

6. Reload, start, and enable the mounts

After creating both mount units, reload systemd's configuration:

$ sudo systemctl daemon-reload

Start the physical SSD mount if it is not already active:

$ sudo systemctl start mnt-ssd_1T.mount

Start the bind mount:

$ sudo systemctl start mnt-backups.mount

To have both mounts activated during normal system startup, enable them:

$ sudo systemctl enable mnt-ssd_1T.mount mnt-backups.mount

The [Install] sections allow these mount units to be enabled for multi-user.target.

7. Verify the mount configuration

Verify the SSD mount

Run:

$ findmnt /mnt/ssd_1T

The output should identify the SSD's filesystem and mount point, for example:

TARGET       SOURCE
/mnt/ssd_1T  /dev/sda1

The actual device name may differ.

Verify the bind mount

Run:

$ findmnt /mnt/backups

The output should identify /mnt/backups as a bind mount of the backup directory on the SSD. Depending on the system and output format, the source may appear similar to:

TARGET        SOURCE
/mnt/backups  /dev/sda1[/backup_SNUBmonkey]

This confirms that /mnt/backups accesses a directory on the SSD rather than a separate copy of the files.

Verify disk usage

Run:

$ df -h /mnt/backups

The filesystem reported should be the one containing the SSD's backup directory, not the root filesystem, assuming the SSD is mounted correctly.

Remember that df reports filesystem capacity, not whether a path is a bind mount. Use findmnt to inspect the mount relationship.

8. Common mistake: Mounting the SSD directly at /mnt/backups

A simpler configuration would mount the SSD directly at /mnt/backups:

/dev/sda1 → /mnt/backups

That arrangement is valid when the entire SSD is intended to serve as the backup filesystem. However, it does not implement the layered architecture described in this tutorial.

The intended design is:

/dev/sda1
    |
    v
/mnt/ssd_1T
    |
    v
/mnt/ssd_1T/backup_SNUBmonkey
    |
    | bind mount
    v
/mnt/backups

This lets the SSD retain its own storage mount point while applications use a dedicated backup path.

9. Troubleshooting: “Target is busy”

Linux may refuse to unmount a filesystem or bind mount if a process is still using it.

Common causes include:

• A terminal whose current directory is inside the mount.
• An active rsync or backup job.
• Plex or another service scanning files.
• Docker containers using the mount.
• Samba shares or other file-sharing services.
• Transmission or other applications accessing files.

Identify processes using the mount

Run:

$ sudo fuser -vm /mnt/backups

You can also inspect open files and processes with:

$ sudo lsof +f -- /mnt/backups

Stop or reconfigure the relevant processes before attempting to unmount the path.

If your terminal is inside the directory, move elsewhere:

$ cd /

Then try to unmount the bind mount:

$ sudo umount /mnt/backups

Unmount the physical SSD only after the bind mount and any other dependent mounts have been removed:

$ sudo umount /mnt/ssd_1T

Avoid lazy or forced unmounts as a first response. They can conceal an underlying dependency problem or disrupt active workloads.

10. systemd mount units versus /etc/fstab

Both systemd mount units and /etc/fstab can configure persistent mounts.

systemd mount units

Dedicated .mount units are useful when you want:

• Explicit dependencies between mounts.
• Clear startup ordering.
• Per-unit status and logs.
• Easier integration with other systemd services.
• Independent control of individual mounts.

You can inspect a mount unit's status with:

$ systemctl status mnt-backups.mount

/etc/fstab

For simpler systems, /etc/fstab is often sufficient. It provides a central configuration file for persistent filesystem and bind mounts, and systemd automatically generates mount units from its entries.

Neither approach is universally better. Choose the one that best fits your system's complexity and maintenance requirements. Dedicated systemd units are particularly useful when explicit dependencies and independent service management matter.

Combining systemd mount units with bind mounts separates physical storage from application paths. Mounting the SSD at /mnt/ssd_1T and exposing backups through /mnt/backups simplifies automation and keeps application paths stable, even when the underlying storage changes.

We hope you found these tips useful.