Which is the correct mechanism for auto-mounting a USB flash drive at boot?

Question

I'm seeing apparently conflicting information on the proper way to auto-mount USB flash drives at boot. Most instructions on how to do it say to use an entry in fstab. Gnome Disks has a built-in feature to automate this entry. It seems to recognize a flash drive as a flash drive and know how to properly make an entry for it in fstab, and the entry works.

On the other hand, I've read that pluggable drives should be handled by uDev rather than fstab, including essentially permanently plugged devices. Consistent with this, Disk Manager (a utility bundled with MX Linux), opens on my system (containing a working fstab entry for a flash drive), with an error message:

I cannot find any existing block devices corresponding to the following devices:
/dev/disk/by-id/usb-Samsung_Flash_Drive_<id> on <mount point>
It is advisable to remove them to avoid failed mount at start-up.

Once that message is bypassed, Disk Manager excludes the (properly mounted) drive from its display. It has an issue with the fact that it isn't a block device, let alone pluggable.

What I assume is a backup for fstab made by Disk Manager at some point, /etc/fstab-disk-manager-save, begins with the comment:

# Pluggable devices are handled by uDev, they are not in fstab.

An observation: auto-mounting a flash drive is a commonplace requirement. As such, one would expect there to be tools to assist in setting this up. The existing tools all seem to do it by creating an entry in fstab. Using uDev appears to require writing your own custom program, and there are many questions on Stack Exchange from programmers needing help with this (so it doesn't appear to be a method for novice users).

There's the old saying, "If it ain't broke, don't fix it", and the fstab entry method appears to work. OTOH, the advice about using uDev and the warning about mount failure means there are some conditions in which fstab won't work for this, which suggests that fstab is the wrong tool for the job and shouldn't be relied on just because it works in some cases.

So should a "permanently" plugged-in flash drive be mounted via fstab or uDev, and what is the risk suggested by the Disk Manager warning?

Answer 1

Eduardo Trápani's comments pointed me in the right direction to research the gist of the issue. I'll close the loop with this self-answer for anyone else landing here.

Problems preventing a successful boot can leave the computer in a state that requires jumping through hoops to get it operational again since you don't have access to the distro's own tools to fix the issue. The basic risk with using fstab for USB flash drives is that booting can hang or go into recovery mode if the drive is considered essential and mounting cannot be completed.

A drive is considered essential if it is in fstab and has not been designated (via relevant options), as only wanted rather than required. A number of conditions can lead to inability to mount, including the drive being unplugged, the drive having failed (commonplace for USB flash drives), or an fsck check being designated in the mount parameters and the system being unable to complete that.

These problems can be mitigated by options specified in the mount parameters, but those options vary in their availability and implementation across distros. So using fstab to mount removable drives benefits from researching the mount options available in your distro, even when using automated tools, like Gnome Disks, to create the fstab entry.

The mount options include:

• nofail: I've read varying descriptions of what nofail does. Some describe this option as simply causing fsck to skip the test if it can't be performed (the test is skipped automatically for missing drives if they have the auto option). Others describe nofail as more generally defining the mount as only wanted, not required. The implication is that the boot will continue regardless of whether the device can be mounted successfully.

• nobootwait: The varying descriptions are similar to nofail. Some descriptions seem to limit its purpose to making the boot not dependent on the ability to start or complete that device's fsck check. If the device is available, it runs fsck concurrently in the background rather than sequentially. The potential side effect (which also applies to nofail), is that the boot could complete but that resource isn't (yet) available, potentially causing operational problems.

  Other descriptions didn't limit nobootwait to fsck; they described it as preventing failure to mount the drive, due to any cause, from halting the boot.

  One post indicated that a difference between these two options is that nofail waits for up to several minutes before deciding that the drive is unavailable, resulting in a boot delay if it is, whereas nobootwait moves on immediately.

  My understanding is that nobootwait was never compatible with Ubuntu (don't know if that extended to some non-Ubuntu-based distros, and can't vouch for whether that still applies at this time).

• x-systemd options: There are some options for directly controlling whether a device is required vs. merely desired, and how long boot will wait for the device. These are named with the pattern x-systemd.<option>, and are contingent on the distro using systemd.