[root tip] [How To] Use systemd to mount ANY device

Difficulty: ★☆☆☆☆

Disk device recognition

Manjaro uses udev (see Arch Wiki) to load devices at boot time. The loading of devices is arbitrary and therefore you cannot predict which device will be available at a given path.

But static device names do exist and you can assign specific locations to your device and thus ensure e.g. scripts will work as expected.

What to learn

  1. Overview of system mount units
  2. Structure and Content of a mount unit
  3. Mount at boot (immediate mount)
  4. Mount on demand (mount on first access)
  5. Permissions
  6. Conclusion

1. What is systemd mount units


The systemd manual has the following somewhat contradicting statement

Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). Mounts listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach. See systemd-fstab-generator(8) for details about the conversion.- system.d.mount.5.html#FSTAB (Emphasized by me)

Logic

As mounts listed in fstab will be converted into native units dynamically at boot - logically we create the units ahead so the system don’t have to bother with converting fstab - the contradiction in above statement is fstab is the preferred approach.

What? Why would it be preferable to use a configuration which must be parsed and converted when you can create native units?

I recommend mount units because

  • They are easy to create
  • They provide clear logic as you can see from below template
    • What
    • Where
    • When
    • Why
    • How
  • Mount on demand (automount) for removable or networked devices

Mount unit template

[Unit]
Description=

[Mount]
What=
Where=
#Type=
#Options=
#TimeoutSec=seconds

[Install]
WantedBy=multi-user.target

Auto mounting a removable or networked device using systemd is a simple secure approach. For one - you don’t have to edit your fstab - small error in fstab can render your system unbootable.

This article will use an USB device which may or may not be available at boot time and when you plug it you want it to be mounted on a special path - it could be dedicated backup disk.

The basics of this guide can also be used to mount any extra devices available in your system, or remote shares e.g. WEBDAV, SMB, FTP and NFS. You can find link to a topic containing sample mount units at the end of this article.

2. Structure and Content of a mount unit


There is no rules as to where you can mount the device. Just remember a few things

  • Structure
  • Recognizable
  • Dont’t use /home your mount may not mount at all
  • Don’t use /run - it is a volatile structure recreated at boot
  • Don’t use /mnt it’s primary use is temporary mount

By structure I mean organizing a directory tree - I usually recommend create a data folder on root and populate the tree with your devices and locations like below.

By recognizable I mean naming your mount point with a logical description of the content - but don’t use dashes anywhere in the mount point - see explanation below. If you really need a double word in your data tree - use a low dash ( _ ). You should also avoid local accented characters (e.g. danish æ ø å Æ Ø Å)

Immediate branches are your devices - and network share mounts in a branch named for the type of fileservice e.g. NFS and SMB.

Sample data tree
 $ tree /data -L 2
/data
├── backup
├── build
├── nfs
│   ├── data
│   ├── music
│   ├── photo
│   ├── video
│   └── web
├── private
├── projects
├── smb
│   └── web
└── virtualbox

The topic revolves around an USB device for backup

If your goal is to mount an internal disk you can skip the automount part as it is not necessary.

Naming the mount units uses a mandatory convention.

Taking the example an USB disk for backup and we want the disk to mount to /data/backup then the filename becomes data-backup.mount

Note: Make sure the filename corresponds to the mountpoint you want to use. E.g. the unit name data-backup.mount can only be used if are going to mount the share under /data/backup. Otherwise the following error might occur: systemd[1]: data-backup.mount: Where= setting does not match unit name. Refusing..

:exclamation: Dashes in the file name represents the directory separator - so don’t use dashes anywhere in the mount point.

Any text editor will do - just remember - the path is system and thus read-only - which means the editor must be able to request permission to save the file.

I use the micro editor - simple yet powerful console editor

sudo pacman -S micro

Open the text editor with new file in /etc/systemd/system using the name data-backup.mount

$ micro /etc/systemd/system/data-backup.mount

Insert the template from above into the file - and modify the description - continuing our backup disk example

[Unit]
Description=Mount Backup disk (/data/backup)

[Mount]
What=
Where=
#Type=
#Options=
#TimeoutSec=seconds

[Install]
WantedBy=multi-user.target

Mount

The section [Mount] is the same data as you see in your fstab - except the What which must the full path to the device. The nature of systemd makes it impossible to rely on the traditional path /dev/sda1 - luckily there is other options

  • /dev/disk/by-uuid/
  • /dev/disk/by-label/

What

To get the device uuid you can use lsblk command and the -no UUID or -no LABEL to retrieve the identification you need for the mount. (substitute sdy1 with your actual device and partition).

If you choose to use LABEL you must ensure you have different labels for all filesystems.

$ lsblk -no UUID /dev/sdy1
67f922cd-a61f-4d5e-84c0-ac8335a7ce67

Then insert the UUID into the file

What=/dev/disk/by-uuid/67f922cd-a61f-4d5e-84c0-ac8335a7ce67

Where

Next type in the path where you want the device mounted. If the path do not exist it will be created.

:information_source: default permissions is 755 owned by root

If your actual device is an existing device and the owner:group UID:GID do not match your device will be mounted read-only.

Where=/data/backup

Caveat using dashes in a folder-name

:exclamation: Comment by @FadeMind
Don’t use a dash - in your path because a dash refer to a new branch on the folder tree and this will break the naming of the mount/automount file

  • Invalid /data/home-backup
  • Valid /data/home_backup
  • Valid /data/home\x2dbackup

To get the correct name for your mount/automount filename when you use dashes in your folder-naming

$ systemd-escape -p --suffix=mount "/data/home-backup"
data/home\x2dbackup.mount

Type

The Type is optional for disk devices - but from the viewpoint - the more information we provide - less work for the system.

You can retrieve the file system the same way as the UUID.

$ lsblk -no FSTYPE /dev/sdy1
ext4
Type=ext4

Other types like NFS, SMB and FTP requires Type to be set.

Options

The Options is optional for disk devices.

As with fstab it takes a comma separated list of options for the filesystem mounted.

Other types like NFS, SMB and FTP requires Options to be set.

Options=defaults,rw,noatime

Save the file

3. Mount on boot


This works just like your fstab - if the device is not available - the system will use the default 90 seconds for the device to be available. The behavior can be changed by setting TimeoutSec= to a value matching the device actual mount time or use an additional automount unit.

First reload the systemd daemon

sudo systemctl daemon-reload

Note the state of the mount

systemctl show -p ActiveState -p SubState --value data-backup.mount

Mount the device

sudo systemctl start data-backup.mount

Now you can verify the service

systemctl show -p ActiveState -p SubState --value data-backup.mount

Note that the folder was created by systemd - list the content of the mount
:information_source: note permissions changed to partition content

$ ls -la /data/backup

If the device is an internal device always available you can enable the mount and your device will be mounted during boot.

sudo systemctl enable data-backup.mount

If - on the other hand - this is an USB device - which is not available at boot time - do not enable the the mount unit but proceed to create an .automount unit for your USB device.

The same rule applies to any remote file system such as SMB, NFS, FTP, WEBDAV, SSH and some which has not yet been invented.

4. Mount on demand


An automount unit is a special unit which takes care of activating the corresponding mount unit when the mount path is accessed. The difference for mount and automount is when it is mounted.

To avoid waiting too long for a hotswapped physical disk device to available add a reasonable timeout the mount unit’s Mount section

[...]
[Mount]
TimeoutSec=10s
[...]

To demonstrate the automount - first unmount the data-mount

sudo systemctl stop data-backup.mount

Verify the content of the mount point - it should now be empty.

ls -la /data/backup

Now we proceed to create an automount for the mount. Create a file - it must be named using the same rule as the mount but with the extension of .automount

sudo touch /etc/systemd/system/data-backup.automount

:information_source:
The automount service will fail if the device path is mounted - only ever enable one - either .mount or .automount.

Automount define

Edit the file and insert the following content - expanding our backup disk example - and save it.

[Unit]
Description=Automount backup partition

[Automount]
Where=/data/backup
TimeoutIdleSec=10

[Install]
WantedBy=multi-user.target

Test automount


Now enable and start the automount for data-backup

sudo systemctl enable --now data-backup.automount

You know you unmounted the device - don’t mount it - just access the /data/backup folder from terminal or a file manager - you will find systemd mounts it behind the scenes.

5. Check permissions


If this is a newly formatted device or a reused device - it is wise to check the permissions. If you get issues with the device being mounted read-only - depending on filesystem - it may be due to the permissions stored on the device.

If the device is using a Linux file system you can change permissions when it is mounted. To change the permissions on your games partition mounted at /data/games

sudo chmod ugo+rw /data/games -R

If your device is a shared device dual booting Windows and Linux and formatted using NTFS and it mounts read-only - reboot your system into Windows and disable features like Fastboot, hibernation, sleep and hybrid sleep as these will taint the filesystem and cause Linux to mount it read-only.

6. Conclusion


This approach is a safer way than editing your fstab. Worst case the device is not mounted - if you make a mistake in fstab - the system breaks.

You can mount all kind of devices - NFS, SMB, FTP, WEBDAV, SFTP, SSH - using this recipe. Sample files for different kind of mounts can be found in this topic.

Crosspost nix.dk

37 Likes

A post was merged into an existing topic: How do I mount a share with a space in the name

Is it also able to mount smb Shares of a Synology NAS?

Systemd mounts anything - provided the right information and options.

I have several shares on Synology NAS - using mount and automount. Entering the mount point either by cli or gui mounts within seconds.

1 Like

getting this.:

● nas-home.mount - NAS SMB home share
     Loaded: bad-setting (Reason: Unit nas-home.mount has a bad unit file setting.)
     Active: inactive (dead)
      Where: /data/smb/home
       What: //<IP>/home/

Okt 13 19:52:00 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:53:42 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:53:45 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:54:34 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:54:36 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:54:38 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:55:06 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:55:09 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:55:11 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.
Okt 13 19:56:16 Workstation systemd[1]: nas-home.mount: Where= setting doesn't match unit name. Refusing.

Read the message - then read the rules on unit naming - also see the sample units

Even sshfs ? I am really looking forward to test this.

yup - also sshfs

3 Likes

wow this is great. :slightly_smiling_face:

Any idea if automount works under “–user” as well? Or it’s strictly privilege thing.

I’ve read something on fedora wiki that it might be set up under root which is sad as I can use Fuse to mount things without needing to modify the system.

I remember trying - but could not get it to work - probably my own fault - but not investigated further as my use is satisfied by the system mount.

You might add that you can generate the correct unit name using systemd-escape(1):

To generate the mount unit for a path:

$ systemd-escape -p --suffix=mount “/tmp/waldi/foobar/”
tmp-waldi-foobar.mount

Already mentioned

Ahh i didn’t notice, because it was hidden by this:

Maybe put the mentioning of it under the portion i quoted :arrow_heading_up: in the open :wink:

How about, once a device is set up (using gnome-disks or fstab) we simply

  1. copy the file from /run/systemd/generator to /etc/systemd/system/
  2. Hash # it from fstab, save/exit fstab
  3. systemd to enable?

I like easy shortcuts. Obviously the automatically generated file isn’t quite up to scratch… tidying up and editing now.

Initially, systemd didn’t like my file and politely declined. However, after a tidy up it seems to be fine - after a reboot, then deleting the hashed lines from fstab it’s automagic.

Thanks for the guide.

However, I did keep the /mnt/T3 and /mnt/T4 paths (as there’d be a few issues raised by changing the path) and I’m curious if there’s really any reason or benefit to create a new folder (/sata for example) to mount my whirly disks?

Well - it is not a problem - as long as you know what you are doing - and you appear to do so.

My recommendation on folder structure is what it is - a recommendation from a long time sysadmin - with autistic treats :slight_smile:.

You know the saying - only a genius can make reason out of chaos - just look at my desk - what a mess.

1 Like

Lolz but it’s a nice guide - no problems after setting up my systemd mounts, thanks for that :wink:

1 Like

2 posts were split to a new topic: Systemd mount unit error

6 posts were split to a new topic: Troubleshooting mount unit naming

A post was split to a new topic: Where do I start - it all seems difficult to learn