As of time of writing, a modern Linux system that uses
systemd cannot accept
duplicate entries in
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
Nov 06 22:14:08 archlinux systemd-fstab-generator: 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: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.
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
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
/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
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
/etc/fstab entirely. Simply do not use
Instead, create a custom
systemd service file that
mount command manually. This essentially
behaves as a custom script while also (roughly) behaving like a
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
#!/usr/bin/env python3 # # Install this at /usr/bin/mount.my-command and make this script executable. import sys import subprocess device = sys.argv mount_point = sys.argv options = sys.argv # 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