> ## Content Index
> Fetch the complete content index at: https://snubmonkey.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Using systemd Bind Mounts to Organize Linux Storage.
- URL: https://snubmonkey.com/linux-systemd-bind-mounts-storage/
- Published: 2026-05-21T00:01:32.000Z
- Updated: 2026-10-16T23:12:43.000Z
- Description: Learn how to configure Linux systemd mount units to separate physical storage from application paths. Set up persistent bind mounts, verify mount points, manage dependencies, and troubleshoot common mounting issues.
- Author: yannick Coffi
- Tags: how to 🪄, tips

### 

# 

## 

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.