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
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
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.
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).
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:
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.
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?
_netdev
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 _.
“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.”
