systemd mounts

2025-08-17

Just a quick note on configuring an automatic network mounted file system.

I have been using Hetzner for the occasional VPS for a while now without issue. Exploring their other offerings a while ago I decided to also utilize their "storage box" service for backups and media. The service is pretty self-explanatory, you pick a size tier and get access via SFTP, SMB, WebDAV, etc. at a fixed price per month. Upon purchasing the service you get a username like u123456 and a server URL that includes that username in a subdomain like u123456.your-storagebox.de, finally you also get a SAMBA/CIFS share URL like u123456.your-storagebox.de/backup.

This all pretty much just works and you can connect using your file explorer using the username and credentials (the same credentials work for accessing it via SFTP).

The most interesting part of all this for me is the CIFS functionality because it means I can mount this storage device into a server that otherwise doesn't have much storage capability. The cheapest VPS I use has a 40GB disk attached and the smallest storage box is 1TB, rather than paying for a volume I'm willing to take a bit of a hit on IO speeds and use a storage box for much less money. The 1TB storage box is €3.20/month whereas a 1TB volume would be €44.00/month ($3.74/$51.43 at time of writing). As far as I know this is due to volumes being more flexible in their ability to be resized and their being backed by solid state drives whereas storage boxes run on hard disk drives and offer limited size options.

All that I need is a way to ensure using the storage is as painless as possible so that I make good use of it. While it is possible to mount the thing at the command line like this (in the case of Debian 13 I needed to install the package cifs-utils to get things working):

mount.cifs -vvv -o user=u123456,pass=hunter2 //u123456.your-storagebox.de/backup /mnt/storage

It isn't persistent across reboots and I am never going to remember the syntax. Instead I want to automate the mounting using systemd.mount. That is pretty straight forward and looks mostly like the above command:

# /etc/systemd/system/mnt-storage.mount
[Unit]
Description=storage storage mount

[Mount]
What=//u123456.your-storagebox.de/backup
Where=/mnt/storage
Type=cifs
Options=user=u123456,password=hunter2

[Install]
WantedBy=multi-user.target

The only interesting thing to note (or for me to remember) is that the "Where" needs to match the name with slashes substituted for hyphens, so "/mnt/storage" becomes "mnt-storage". While this is enough to get a working mount, startable with systemctl start mnt-storage.mount it wasn't quite enough to have things fully automated. The .mount definition will set things up on boot but I have received a few notices from Hetzner about maintenance on the storage servers that may lead to downtime. I haven't personally noticed any downtime yet because I'm not watching the thing like a hawk. It did raise a question for me about how to try to ensure the mount was as available as possible.

For that I needed a second file to define an automount. The automount will mount the file system at the time that it is used.

# /etc/systemd/system/mnt-storage.automount
[Unit]
Description=automount remote storage

[Automount]
Where=/mnt/storage

[Install]
WantedBy=multi-user.target

In the event the mount is already set up there is no effect but if things are not running or have been stopped there is a pretty nice recovery flow which can be seen here:

# systemctl stop mnt-storage.mount
Stopping 'mnt-storage.mount', but its triggering units are still active:
mnt-storage.automount

# systemctl status mnt-storage.mount
○ mnt-storage.mount - storage mount
     Loaded: loaded (/etc/systemd/system/mnt-storage.mount; disabled; preset: enabled)
    Active: inactive (dead) since Mon 2025-08-18 03:27:57 UTC; 9s ago
   Duration: 4min 41.022s
 Invocation: 85678ca8b9dd4426b204a8e25306ef9b
TriggeredBy: ● mnt-storage.automount
      Where: /mnt/storage
       What: //u123456.your-storagebox.de/backup
   Mem peak: 1.7M
        CPU: 28ms

Aug 18 03:27:57 debian-4gb-fsn1-1 systemd[1]: Unmounting mnt-storage.mount - storage mount...
Aug 18 03:27:57 debian-4gb-fsn1-1 systemd[1]: mnt-storage.mount: Deactivated successfully.
Aug 18 03:27:57 debian-4gb-fsn1-1 systemd[1]: Unmounted mnt-storage.mount - storage mount.

# ls /mnt/storage/
backups  media

# systemctl status mnt-storage.mount
● mnt-storage.mount - storage mount
     Loaded: loaded (/etc/systemd/system/mnt-storage.mount; disabled; preset: enabled)
    Active: active (mounted) since Mon 2025-08-18 03:28:25 UTC; 6s ago
 Invocation: 211cb28a7d9542e6a8f98acf7fd60e67
TriggeredBy: ● mnt-storage.automount
      Where: /mnt/storage
       What: //u123456.your-storagebox.de/backup
      Tasks: 0 (limit: 4459)
     Memory: 12K (peak: 1.7M)
        CPU: 15ms
     CGroup: /system.slice/mnt-storage.mount

Aug 18 03:28:25 debian-4gb-fsn1-1 systemd[1]: Mounting mnt-storage.mount - storage mount...
Aug 18 03:28:25 debian-4gb-fsn1-1 systemd[1]: Mounted mnt-storage.mount - storage mount.

In case it isn't clear, I'm stopping the mount to try simulating some error condition or maintenance event. The remote is unmounted but listing the mount directory causes the filesystem to be seamlessly remounted. That then is sufficient for anything I'm planning, just need to remember to systemctl daemon-reload and systemctl enable mnt-storage.automount

That's all it takes and so far everything else seems to just work to treat the mounted directory no differently than any other mount. That includes doing things like running a container to launch a media server on the VPS but using the mounted storage as the primary library location. Or setting up a nightly backup job that writes to the storage box to guard against any data loss on the server itself.