DietPi-Drive_manager config doesn't include x-systemd.automount for mount on reboot

[EdEstes]

Greetings.

Just installed DietPi 6.26 on a Raspberry Pi 4 (buster) and ran into an issue.

I used DietPi-Drive_manager to configure my network drives and everything was configured correctly in the fstab file. The problem is the drives do not automatically mount at startup. I am able to type:
sudo mount -a
to get the network drives to mount. After doing some research, I found this thread that identified the problem/solution:
https://dietpi.com/phpbb/viewtopic.php?f=9&t=6190
By manually adding "x-systemd.automount" to each share in the fstab configuration, the drives would mount at boot time.

Shouldn't this be included when using the preferred "DietPi-Drive_manager" configuration tool?

Thanks!

[MichaIng]

@EdEstes
Many thanks for your report. I'm currently running some tests since this had not been an issue before, but you're not the only one reporting it + the linked forum thread.

On Stretch this is not an issue:

Oct 26 20:33:51 VM-Stretch systemd[1]: Reached target Network.
Oct 26 20:33:51 VM-Stretch systemd[1]: Starting DietPi-Boot...
Oct 26 20:33:51 VM-Stretch systemd[1]: Reached target Network is Online.
Oct 26 20:33:51 VM-Stretch systemd[1]: Mounting /mnt/nfs_client...
Oct 26 20:33:51 VM-Stretch systemd[1]: Starting Permit User Sessions...
Oct 26 20:33:51 VM-Stretch systemd[1]: Mounting /mnt/samba...
Oct 26 20:33:51 VM-Stretch systemd[1]: Started Permit User Sessions.
Oct 26 20:33:51 VM-Stretch kernel: FS-Cache: Loaded
Oct 26 20:33:51 VM-Stretch sh[360]: eth0=eth0
Oct 26 20:33:51 VM-Stretch kernel: Key type dns_resolver registered
Oct 26 20:33:51 VM-Stretch kernel: FS-Cache: Netfs 'nfs' registered for caching
Oct 26 20:33:51 VM-Stretch kernel: NFS: Registering the id_resolver key type
Oct 26 20:33:51 VM-Stretch kernel: Key type id_resolver registered
Oct 26 20:33:51 VM-Stretch kernel: Key type id_legacy registered
Oct 26 20:33:51 VM-Stretch kernel: FS-Cache: Netfs 'cifs' registered for caching
Oct 26 20:33:51 VM-Stretch kernel: Key type cifs.spnego registered
Oct 26 20:33:51 VM-Stretch kernel: Key type cifs.idmap registered
Oct 26 20:33:51 VM-Stretch systemd[1]: Mounted /mnt/nfs_client.
Oct 26 20:33:51 VM-Stretch systemd[1]: Mounted /mnt/samba.

Both mounts are started after network-online.target has been reached, which means that network should be fully initialised. This is as it should be since both, we add the _netdev mount option, and even without systemd should recognise that it's a network drive: http://codingberg.com/linux/systemd_when_to_use_netdev_mount_option

On Buster:

Oct 26 20:48:49 VM-Buster systemd[1]: Reached target Network.
Oct 26 20:48:49 VM-Buster systemd[1]: Starting Permit User Sessions...
Oct 26 20:48:49 VM-Buster systemd[1]: Starting DietPi-Boot...
Oct 26 20:48:49 VM-Buster systemd[1]: Reached target Network is Online.
Oct 26 20:48:49 VM-Buster systemd[1]: Mounting /mnt/samba...
Oct 26 20:48:49 VM-Buster systemd[1]: Mounting /mnt/nfs_client...
Oct 26 20:48:49 VM-Buster systemd[1]: Started Permit User Sessions.
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: Loaded
Oct 26 20:48:49 VM-Buster kernel: Key type dns_resolver registered
Oct 26 20:48:49 VM-Buster sh[305]: eth0=eth0
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: Netfs 'nfs' registered for caching
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: Netfs 'cifs' registered for caching
Oct 26 20:48:49 VM-Buster kernel: Key type cifs.spnego registered
Oct 26 20:48:49 VM-Buster kernel: Key type cifs.idmap registered
Oct 26 20:48:49 VM-Buster kernel: NFS: Registering the id_resolver key type
Oct 26 20:48:49 VM-Buster kernel: Key type id_resolver registered
Oct 26 20:48:49 VM-Buster kernel: Key type id_legacy registered
Oct 26 20:48:49 VM-Buster systemd[1]: Mounted /mnt/nfs_client.
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: Duplicate cookie detected
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: O-cookie c=00000000e085fcad [p=0000000075215242 fl=222 nc=0 na=1]
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: O-cookie d=0000000086e76933 n=000000003ba816b7
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: O-key=[6] '646965747069'
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: N-cookie c=00000000ea206f77 [p=0000000075215242 fl=2 nc=0 na=1]
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: N-cookie d=0000000086e76933 n=00000000f8db303e
Oct 26 20:48:49 VM-Buster kernel: FS-Cache: N-key=[6] '646965747069'
Oct 26 20:48:49 VM-Buster systemd[1]: Mounted /mnt/samba.

Looks fine as well.

However what is a bid of a risky thing, that leads to some other issues as well and can be seen from both logs, is that the "allow-hotpolug" interfaces, as we define them in /etc/network/interfaces (to not block boot if e.g. WiFi adapter is not plugged and such), finish full initialisation AFTER network-online.target as been reached (The eth0=eth0).
This is since they for a while run as "Type=simple" services, due to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791920
This allows the target to be reached already when those interfaces "start" to be configured, so it is not required that this process finishes. Hence, with allow-hotplug, network-online.target does not necessarily mean network online, hence things like network mounts can theoretically fail.

If you find time, could you remove x-systemd.automount, reboot and paste the related part of journalctl that includes network targets and mounts?

---

However x-systemd.automount, regardless of the above, totally makes sense! Often network drives are not used continuously and are not required on boot, so this as well takes additional load from boot, especially as well if the server is simply not online.

And really, automounts are indeed mounted immediately when you access the mount point, even network mounts. Its as if they were mounted already (subjective feeling).

The consequence is then to add "noauto" and "nofail" as well, and do the same for all external drives btw. (as long as not root or boot file system on it). Currently noauto is missing there, although I thing x-systemd.automount excludes automated mount anyway 🤔.

[MichaIng]

Done: bdddd83

[alexeylutskov]

I manually added noauto, x-systemd.automount to each fstab share, but it still not function as expected. For example Drive Manager and Backup not responding when launched, MPD not playing after reboot.

[MichaIng]

@alexeylutskov

For example Drive Manager and Backup not responding when launched

What you mean by this? dietpi-drive_manager does not show the drive and dietpi-backup hangs or other tools?

Which device, RPi as well? Note that in some cases x-systemd.automount is not supported, e.g. the kernel module autofs4 not available on specific board. You should be able to check automount and mount status by:

systemctl status mnt-<name>.automount
systemctl status mnt-<name>.mount

With <name> being the mount point below /mnt. Any mount point (path) can be checked by this, however slashes need to be replaced by dashes.

Logs can be also check via:

journalctl -u mnt-<name>.automount
journalctl -u status mnt-<name>.mount

[alexeylutskov]

Thanks!

I'm using rpi 4, services were just hanging when launched , noe all works fine, but before that I removed nofail and changed smb to 2.1