I wish to do this because I am experiencing bootup hangs I thought I had previously resolved, but have reappeared - perhaps the drive is failing. I have been using systemd.automount in lieu of autofs for remote mounts successfully for some time (thanks to hcvv for the suggestion).
Is there any reason I should not do this? I welcome any suggestions for improving or modifying the syntax of the entry.
Nver tried this, but I have no idea why it should not work as you intend (apart from that fact that it was probably never designed for this goal: a possibly failing mass-storage device).
One thing only. The _netdev option is already superfluous in an NFS mount, bit in this case it looks a bt out of place. Although it should not matter I guess.
I would say: just try it. It will not break the device (more then it is already).
Thank you. One point - the protocol is NTFS, not NFS. The remote, network mounts are NFS - but this is directly off the PC via a USB port. Does that make a difference?
The drive is a Western Digital enterprise drive (I believe an RE3 version) in an Antec enclosure. It’s not new - but these drives have been fairly reliable. So it may be some other issue that causes the drive to hang.
NTFS is not a protocol, it is a (non-Linux) file system type.
NFS is a protocol, but for mounting it is also a file system type.
I do not think the hardware has anything to do with this. It presents itself as mass-storage through an USB connection to the system (kernel). The kernel will tell the udev daemon and that will create block device files in /dev so that it can be used.
The automount function (of systemd or the earlier implementation) only is for mounting it when asked for and umounting it when not needed. That should normally not be needed for a device that is available from boot until shutdown, but you have a reason to use this feature. So why not?
But again,why do you not simply try? And tell us what your experiences are. Mounting and unmounting will do no damage.
Thank you. Perhaps I am mixing apples and oranges (NTFS and NFS). For completeness, here is the current version of my fstab on the machine in question:
The mounts using UUID were generated during installation and I added everything below that, beginning with the USB drive ("LABEL etc.). I recognize that only the remote platform D drive follows your suggested syntax - and I plan to remove all three drives (D,F & G) from that box in the near future (my former primary workstation), so those lines will then be deleted.
Anything in fstab I should change? It does work, so it isn’t broken (as they say).
Maybe you mix apples and pears, but it is sure you are overcautious. Don’t mix in things that have nothing to do with what you are trying to do: making that one mount and automount.
So, unmount that file system, make a copy of that one line, prefix one of those with a # (that then is your backup, to make switching back to the existing situation easy).
Change the other one to what you suggested (maybe without the _netdev, as I suggested) and see what happens.
It a reboot might be needed, but even that is not sure, so easy is it.
Go to some file in that file system and see if you can access it. When yes, end of test and success. When no, end of test and fail.
Go, do something and do not try to collect more threatening monsters.
Thank you. I will try that and get back to you. Hopefully, I will be able to reboot (this morning required a number of tries on startup - perhaps the drive is failing and gummed up the works).
This drive does have an NTFS file system on it, so there are some points to be considered:
[ul]
[li]NTFS is not a Linux but a Microsoft Windows file system [/li][li]In Linux there are two file system drivers available which can handle the NTFS file system:[/li][LIST]
[li]ntfs[/li]this driver is part of the Linux kernel and only allows to read a NTFS file system BUT NOT to write to it.
[li]ntfs-3g[/li]this is a user space driver (package https://download.opensuse.org/distribution/leap/15.3/repo/oss/x86_64/ntfs-3g-2016.2.22-3.5.1.x86_64.rpm) which allows to read and write to NTFS file systems. However i do not know if that driver will work with systemd.automount.
[/ul]
[li]If a NTFS file system is shared with MS Windows it might be left behind (by MS Windows) in a state which only MS Windows can deal with (hints: fastboot, hibernate, …). [/li][li]If a NTFS file system gets corrupt probably none of those drivers will be able to repair it and chances are that the drivers will refuse to mount it. So you might need MS Windows to repair a corrupt NTFS file system. [/li][/LIST]
As far as i know the nofail mount option should actually prevent bootup hangs. So if you still see them it might be worth to investigate them in more detail; e.g. (as root)
journalctl -p 3
or you could mount the drive manually (not via fstab) from a command line
mount -t ntfs LABEL=WD750 /z/WD750
in order to see if there are any errors.
To see if the drives hardware is (becoming) faulty you could run
smartctl -x /dev/sdx
(you will have to adjust “/dev/sdx”) But depending an the SATA-to-USB converter in your external drive enclosure smartctl might not give proper results.
Since my last post in mid-August, the issue seems to have resolved itself without my intervention, perhaps due to a patch. No bootup or hardware issues.
Further, the systemd.automount fstab entry I substituted in lieu of the “nofail” code (see the first post) is also working without incident.
Thanks to everyone for their comments and suggestions.
