fstab alternatives for mounting external drive partition

My system includes an external drive, permanently connected via USB (a Western Digital 750 MB magnetic drive in an Antec enclosure). On the KDE desktop, I access the drive either through luckyBackup (frequently) or Dolphin (infrequently).

Until now, I have used the following entry in fstab to mount the drive:

LABEL=WD750  /z/WD750  ntfs  defaults,nofail 0  0

Because the drive occasionally fails to mount during bootup, I added the “nofail” option to avoid a system hang.

In light of deano_ferrari’s comment in another thread

Most users would just use the udisks/udev/DE mounting mechanism to detect and auto-mount USB media . . .
[https://forums.opensuse.org/showthread.php/536341-automount-settings?p=2905224#post2905224], I have begun to question my approach.

If the drive mounts automatically during bootup [/dev/disk/by-label/WD750], would autofs or some other scheme be a preferable alternative to fstab?

A brief review of the openSuSE reference manual and posts on various forums did not yield a clear answer.

IMHO using fstab is a correct way of doing it. You could use autofs (the old automounter) or it’s new replacement systemd.automount (which again uses fstab), but why? It is always there, it should be mounted always. This is like every other file sytem use use in that system. And they are all in fstab.

The only problem you seem to have that on boot it sometimes seems not to be available. Maybe you should address that first before going on the adventure path.

It is possible though that the disk is a slow starter and thus not always ready at boot time mounting. Then only mounting it when needed (automounter) might help.
To show you an example, I have one here with the following options in fstab


Henk -

Thank you for the reply and suggestion. I will look into the systemd.automount option.

For now, before I boot up the machine, I’m checking the drive to see that it is in fact spinning.

If the drive continues to work without any hiccups, I might leave well enough alone.

Thanks again.

I too have had my USB attached drives fail to mount via /etc/fstab.
Something since 15.1 has caused some USB drives not to be seen for up to 15 seconds after the Desktop is up.
It does not matter if if is a rotating drive or an ssd or a nvme attached USB drive.
My cure under MATE desktop is a startup app that runs as root and mount all my USB drives after sleeping 25 seconds. I no longer use fstab for them. This is also better because if the Desktop fails to start properly - the init 6 to reboot is much faster.

Since it takes a while for USB drives to appear - that is my workaround for “slow to show USB drives” (I have 4 on each of my 6 machines).

I once thought it might be that some were NTFS, some GPT, but no difference if NTFS, ext4, GPT or MSDOS. I suspect udev is waiting for them to go ready - failing and trying again after 15 seconds and repeating until successful.

But that depends very much on that particular user starting in in that desktop. That might fit you, but when there are other users or when those file systems are needed by the system even without any user loged in, it is not a solution.

I guess starting the same run from root’s crontab using @reboot as the time and date fields, will circumvent these restrictions.

Henk -

After reviewing your response in post #2 above and looking at some materials discussing systemd and autofs, I am considering converting my remote autofs-mounted shares to fstab entries using the systemd options you suggested. I opted for autofs last year to avoid system hang during bootup when the remote shares were not present.

While setting up auto.master and auto.misc was a fairly simple exercise and the arrangement works well, the advantage of sytemd would be one central location for mount assignments (in fstab).

Do you foresee any downsides?

Using the systemd feature is, I think, the way of the future (like so many systemd features). Good old (since the 1970’s?) auto.master, etc. is, as you say, also easy to do and I do not think it will vanish in the near future. Maybe sometime it will be deprecated, but there are so many “deprecated” features that still work after years, thus when it happens (if it will happen), you will have ample time to convert Thus it is up to you.

I use it on an NFS mount. I had another way of mounting this (not when needed, but when available) and wanted to test systemd.automount just out of curiosity. Until now I am satisfied with it.

To be complete, this is my fstab entry (from which I posted the relevant options above). Remark the _netdev option there:

boven.henm.xs4all.nl:/home/wij             /home/wij  nfs   noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,_netdev,x-systemd.idle-timeout=5min          0  0

Yet another alternative: Let the device notifier mount the external drive automatically and specify the mountpoint in fstab:

erlangen:~ # egrep 'GARMIN|FR' /etc/fstab 
UUID=6914-84F3                             /GARMIN                 vfat   user,**noauto**                   0  0
UUID=0267-906F                             /GARMIN-KART            vfat   user,**noauto **                  0  0
LABEL=FR735                                /FR735                  vfat   user,**noauto**                   0  0
erlangen:~ # 

There will only be a device notitfier when some end-user is logged in.

This is no solution if one needs the file system “for the system” (regardless if some user logged in in the GUI).

Sure. The top post says:

My system includes an external drive, permanently connected via USB (a Western Digital 750 MB magnetic drive in an Antec enclosure). On the KDE desktop, I access the drive either through luckyBackup (frequently) or Dolphin (infrequently).

For doing so the solution is easy to configure and works reliably. Failure to mount will cause no system hangs.

Matter of taste. I prefer a more general, Unix/Linux like approach.

BTW, when the OP says “I access …”, it is always unclear to me who is the “I” in this (and many other sayings on the forum) story. The system does have no concept of “I”. It knows users.
And while Dolphin certainly is something to be used from the GUI, I do not know about luckyBackup (do not know the application). Thus it could even be that the “I” from the OP uses software from the CLI (without a GUI being started).

As said, I try to avoid all those “it may work when …, and when …, etc.” by choosing Unix solutions as they have worked since more then 50 years whenever that is possible.

But it is all a matter of taste and maybe a matter of being old-fashioned.

Henk -

Thank you for pointing out the _netdev option.

If I understand it correctly, the option is needed because during bootup, the NFS server may not be available when the remote share is mounted. The seems to be the sequence in my boot.log. Is this correct?

Yes, that is what I remember.
I am trying to find the documentation of _netdev in a man page, but failed until now.

Found it in

man 8 mount


The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system).

Strange one, it is the only one starting with a _.

Henk -

Thank you. Here’s where I found the information that spurred me to look at my boot.log:


Thanks for that link. Nice article. So we do not need it, but it does not harm.:wink:

I would like to change the last sentence

consider using systemd-automount option, it’s similar to what autofs does, but it’s easier to configure.


consider using systemd-automount option, it’s similar to what autofs does, and it’s even a bit easier to configure.

man systemd.mount

“Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.”

“_netdev: Normally the file system type is used to determine if a mount is a “network mount”, i.e. if it should only be started after the network is available. Using this option overrides this detection and specifies that the mount requires network.”