Even sshfs ? I am really looking forward to test this.
yup - also sshfs
wow this is great.
Any idea if automount works under “–user” as well? Or it’s strictly privilege thing.
I’ve read something on fedora wiki that it might be set up under root which is sad as I can use Fuse to mount things without needing to modify the system.
I remember trying - but could not get it to work - probably my own fault - but not investigated further as my use is satisfied by the system mount.
You might add that you can generate the correct unit name using systemd-escape(1):
To generate the mount unit for a path:
$ systemd-escape -p --suffix=mount “/tmp/waldi/foobar/”
tmp-waldi-foobar.mount
Already mentioned
Ahh i didn’t notice, because it was hidden by this:
Maybe put the mentioning of it under the portion i quoted in the open
How about, once a device is set up (using gnome-disks or fstab) we simply
- copy the file from /run/systemd/generator to /etc/systemd/system/
- Hash # it from fstab, save/exit fstab
- systemd to enable?
I like easy shortcuts. Obviously the automatically generated file isn’t quite up to scratch… tidying up and editing now.
Initially, systemd didn’t like my file and politely declined. However, after a tidy up it seems to be fine - after a reboot, then deleting the hashed lines from fstab it’s automagic.
Thanks for the guide.
However, I did keep the /mnt/T3 and /mnt/T4 paths (as there’d be a few issues raised by changing the path) and I’m curious if there’s really any reason or benefit to create a new folder (/sata for example) to mount my whirly disks?
Well - it is not a problem - as long as you know what you are doing - and you appear to do so.
My recommendation on folder structure is what it is - a recommendation from a long time sysadmin - with autistic treats .
You know the saying - only a genius can make reason out of chaos - just look at my desk - what a mess.
Lolz but it’s a nice guide - no problems after setting up my systemd mounts, thanks for that
thank you SO MUCH for this. its working fine up to now and it’s not as scary as messing with the fstab file
The downside of this seems to be that drives don’t get trimmed anymore by the fstrim.service. At least it seems like it when checking with journalctl -u fstrim
, since fstrim seems to relate to the fstab file. Am i correct or or is there a workaround?
Try
sudo systemctl enable fstrim.timer