Solution for Automount without fstab


Lately i face some problems with fstab struggling to mount my backup disks (by-UUID) and disks for virtual machines and cause it can't reach them i face emergency shell. So I'm looking for a solution without using fstab like a shell script executed as autostart when System already is boot-up. It's just normal HDD/SDD so sdX used as external storage so not necessary for boot-up but good to be still mounted as well. I appreciate some tipps, thanks!

Can you show us the contents of /etc/fstab? Maybe there is a formatting error that be solved easily without resorting to other workarounds.

Sure, but it worked before and i don't edit it after (only when i face boot-up failure i uncomment the backup-drives (all drives that's not part of my Virtual Group). And when i boot-up and reverse the uncomment and check with sudo mount -a after sudo systemctl daemon-reload it works. All in all it's no big deal to mount it later with Session start and i don't need to wait for the emergency shell. As reminder some drives are old age too can be something to do with it.

Here are the parts of the optional data drives in fstab (on other physical disks):

#swap was on /dev/sda1 during installation
UUID=82baf182-1293-4365-b100-bb5d3f1d7ee1 none swap sw 0 0
UUID=0a8c54f2-bb3c-4b77-8e23-15f204ec2660 /mnt/vbox-disk ext4 defaults,rw,errors=remount-ro 0 0
UUID=8264525B64525251 /mnt/volume-win ntfs defaults,rw,errors=remount-ro 0 0
UUID=07ed2f0d-250d-4915-b4ac-2d5b8309e305 /mnt/grab btrfs defaults,rw 0 0

Have you identified which of these drives is causing issues? Maybe it's just one of these that is problematic so you'd avoid having to mess too much with this.

But so far my only guess would be that these drives are taking a bit longer to be detected, so you can try adding a nofail and/or a x-systemd.device-timeout options.

The nofail will simply not report any errors but it's likely that the drives won't be mounted, so you'd still have to resort to either manually mount them with mount -a or another script. The x-systemd.device-timeout will wait a number of seconds for the device to be available. For example:

UUID=07ed2f0d-250d-4915-b4ac-2d5b8309e305 /mnt/grab btrfs defaults,rw,nofail,x-systemd.device-timeout=5 0 0

Note that this will delay your boot times by whatever amount of seconds you choose. But make sure you don't wait for "0" seconds as that's an infinite timeout.

Another option is to use x-systemd.automount instead which would only mount the drive when it's first accessed, instead of mounting it during boot.
Or use autofs if you prefer not using systemd.


No it's not 100% persistent, but it seems like when there is a problem than i got an error for all SATA drives (something like "can't reach ") but i got no problem (at least for now) mounting them later. Reminder: My System / /home is on a NVME VG (2x physical disks).

The nofail prevent the emergency shell in this case and it just would skip mounting it when failed? And without combining nofail with " x-systemd.device-timeout would i have a internal-delay of something like 90s (didn't count - but there is some automatic pending timer, that's not infinite) where it keep attempting to mount the disk? And when I use both in combination and all works fine (=no mounting error) would x-systemd.device-timeout still delay the boot-up or just reduce the internal timer (which is something like 90s in case of an error)?

Not quite sure how it works, just in the case i have a anacron-script for backup that create a compressed backup on /mnt/backup but without a mount it's just a folder on the wrong physical disk / would it notice the access and mount it or do i point to /dev/sdX for a effect? And auto =! x-systemd.automount ,right?

Sorry for the many questions and i really appreciate your help! :slight_smile:

The "sometimes it works" situation can mean different things. It could be a faulty device, or it could also simply be that some drives are loaded in different order every time, and since some drives are slower than others there's a race condition where the drives are not yet operative when the system attempts to mount them.

In any case, it's a good idea to rule this out by running a filesystem check using the fsck command. It may be a bit tedious and time consuming but at the same time it's always good to detect any problems before there's any data loss.

Correct. The nofail option simply ignores any errors reported when a drive specified in the /etc/fstab is not found or has some other issue. As far as I'm aware there's no timeout for this, so if the drive can't be mounted for whatever reason it'll just be ignored and carry on with the next one.

The combination of nofail and x-systemd.automount would still delay your boot time if there's an actual error. The purpose of nofail is simply to allow the system to boot normally, while x-systemd.automount gives more time for the disk to be correctly mounted without errors. If you set a timeout period of 10 seconds but the drive mounts correctly at 4 seconds, then that's all the delay you'll get. If all goes well, however, there should be no delay at all.

In theory, and here I must disclose that I haven't use this feature myself, it should detect any access to the defined mount point and then attempt to mount the drive before doing any filesystem operation. Both x-systemd.automount and the autofs package should have the same effect, but they differ in where they get the information regarding the mount point. The former reads /etc/fstab while the latter reads from /etc/auto.master. Note that autofs is an actual package you must install separately.
This is in essence the same solution as the above: mount the drives at a later point other than boot. The only difference is that this will wait until you actually need it, rather than explicitly waiting for it at boot time.

The mount option auto is different to this, it simply tells the system that the drive can be mounted during boot or when running mount -a. The opposite of this is noauto which simply means that you must explicitly mount this drive manually, but again not related to the other options.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.