As of time of writing, a modern Linux system that uses /etc/fstab and systemd cannot accept duplicate entries in /etc/fstab.

The Problem

See here for a failing example.

# /etc/fstab

...

/dev/mapper/backup-rotating-1 /mnt/backup-rotating ext4 defaults,nofail 0 2
/dev/mapper/backup-rotating-2 /mnt/backup-rotating ext4 defaults,nofail 0 2

In this example two cryptsetup devices that are used for backups are on a rotating schedule. At any given time only one of those two disks is connected to the computer while one is offsite at a secure location.

Even though there are two unique UUID entries for either device and they are mapped to two unique /dev/mapper entries, systemd complains like so.

Nov 06 22:14:08 archlinux systemd-fstab-generator[572]: Failed to create unit file /run/systemd/generator/mnt-backup\x2drotating.mount, as it already exists. Duplicate entry in /etc/fstab?
Nov 06 22:14:08 archlinux systemd[568]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.

The systemd fstab generator service creates entries/files based on the mount point name. An error occurs because the fstab example above has two entries both sharing the /mnt/backup-rotating mount point.

Possible Solution: Unique Mount Points

The most obvious answer is to use unique names for the mount points as we cannot use the same mount point twice.

# /etc/fstab

...

/dev/mapper/backup-rotating-1 /mnt/backup-rotating-1 ext4 defaults,nofail 0 2
/dev/mapper/backup-rotating-2 /mnt/backup-rotating-2 ext4 defaults,nofail 0 2

By having /mnt/backup-rotating-1 and /mnt/backup-rotating-2 the problem is resolved, but this might not be ideal. There are reasons one may intend to re-use the same mount point for multiple devices. If it is known that fstab entries are mutually exclusive and will never actually be mounted at the same time, then the example of rotating devices mounted at a single mount point may be valid.

Some users may have rotating USB devices that rotate for backups or data transfer, and scripts and applications would behave better if an identical mount point could be used for each unique device.

Possible Solution: Custom Systemd Script

Bypass /etc/fstab entirely. Simply do not use /etc/fstab.

Instead, create a custom systemd service file that runs the mount command manually. This essentially behaves as a custom script while also (roughly) behaving like a “normal” fstab generated mount service.

This could be used in conjunction with custom config files and custom mount scripts.

Possible Solution: Custom Mount Script

Create a custom mount script at /usr/bin/mount.my-command. This would then also have to be paired with a customized /etc/fstab entry.

#!/usr/bin/env python3
#
# Install this at /usr/bin/mount.my-command and make this script executable.

import sys
import subprocess

device = sys.argv[1]
mount_point = sys.argv[2]
options = sys.argv[4]

# Any customization could be done here to the `mount` command that is run.
mount_command = ['mount', '-o', options, device, mount_point]

output = subprocess.run(
	mount_command,
	capture_output=True
)

if output.returncode != 0:
	print("error mounting")
	print(output.stderr.decode('UTF-8'))
	sys.exit(output.returncode)

It’s possible to then create a config file like /etc/my-command.conf that the mount.my-command script can read. Anything is possible here, but this is very non-standard and bespoke.

Here is a possible /etc/fstab entry that could be used with a custom mount script. Here custom options are specified that the mount script could then read.

# /etc/fstab

...
/dev/null /mnt/backup-rotating ext4 defaults,nofail,disks=/dev/mapper/backup-rotating-1,disks=/dev/mapper/backup-rotating-2 0 2