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
- Overview of system mount units
- Structure and Content of a mount unit
- Mount at boot (immediate mount)
- Mount on demand (mount on first access)
- Permissions
- 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.mountcan 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..
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.
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
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
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
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
.