I thought using UUID (being Universally Unique Identifier) for a device in fstab would “overcome” the issues you mention above.
Using PARTUUID is even a more robust way as it will “survive” even if the UUID of a device would change through formatting a partition but not if one creates a new partition table.
Yes, but this requires you to know upfront which UUIDs you have. I like to tinker with SBCs, and I have a nice collection of µSD-cards with different OSes on them, maybe 60 cards, give or take. I’m not going to catalogue those. I want to insert them and mount them without knowing what it may be. Same for some hard drives I have lying around. I want to put them into the USB adapter station and mount them to see what the contents are. I am also likely to reformat them or put a different image on them, giving them a new UUID/PARTUUID.
The GUI does this without issues. I can replicate the behavior on the command line with udisksctl. I think fstab should be reserved for drives which are not going to change and are always there. Everything else should be mounted under /run/media/$USER. The GUI does this for you as well, why deviate from the established practice?
Now that you mention your specific use case, then using fstab is rather impracticable.
It wasn’t that obvious from your post marked as solution.
Yes, for removable devices, this is where the system mounts them by default, I guess.
What is a bit baffling is that you say that it has to do with Wayland. Does your script work as intended in a X11 session as it used to do before?
I only want to replicate this behavior. My use case is extreme, but regardless if it’s one removable or sixty, it should go automatically to /run/media/$USER. Using fstab for this, even if you just have a small set, defeats the purpose of /run/media on modern systems. I think using fstab for anything besides permanent, always mounted disks is obsolete. It’s just a practice from times when nothing else was available.
It pays to keep your system clean in the long run, imho. Helped me a lot with unattended small SBCs running in the basement for years, and suddenly I had to work with them again. Much easier if you follow standard practice.
Yes, otherwise I couldn’t have logged in with X11 as a first workaround. It always worked automatically under X11. Under Wayland, it wants credentials, and there’s not even a prompt where to enter them.
I am just speculating here but what if you ran your script as a systemd service?
As said, I am only speculating but this would be the option I would personally try.
If it works, then fine. If not, nothing lost.
Perhaps you would need to look into adding your user to storage group and modify the polkit rules.
Do some research to see if this might be the way to go.
Reference:
Yup, this is the way I’m exploring now. Thanks for the links. I think I need to go this route, but to have a starting point is quite helpful.
It’s a bit off because the udisksctl mechanism (and the GUI equivalents) was designed explicitely so that a userland mount without special privileges was possible.
IF it really turns out this way, the latest Wayland designs are counter to these earlier system design decisions.
Under GNOME-Wayland, whatever removable storage device I may have plugged in at boot are automatically mounted at /run/media/$USER
Also under the running session, whatever other removable device hot-plugged into the system will be automatically mounted at said location.
Does this mean that the issue you are having is rather Plasma-Wayland related?
I think the whole topic is wrong. 
Maybe. With KDE, disks only get mounted if you click on them in Dolphin. But with Gnome/Wayland, they don’t get mounted before login, or do they? You would still need something if you want to login remotely.
In retrospect, yes. But as they say: Hindsight is 20/20.
I don’t have a Plasma system at the moment to check but from the top of my head:
System Settings → Hardware → Removable Storage → Removable Devices
and then enable automatic mounting of removable devices.
If the above is correct, would that work for auto-mounting devices already connected when booting up or just when hot-plugged?
Err… good question. Not being my use case, I have never thought of this. I just did a test (posted above) to see if attached devices to the computer get mounted automatically upon boot.
Adding this for Plasma 6 context
System Settings > search “device auto-mount”, or
System Settings > Connected devices > Disks and cameras > Device Auto-Mount
Great! That’s exactly what I had on my mind though it looks a bit different now.
Thanks!
Doesn’t look much different to a Plasma 5 installation, but I rarely use these settings. I am a CLI guy with the occasional browsing, which I have to do in a GUI. Note the ‘on login’ and ‘on attach’ columns. This makes it clear that a mount won’t happen before login.
I am going to try if this works with autologin as well, which could make it automatic after a reboot. But what’s about security then?
The one thing which irks me with these GUI solutions: You need to make the changes for each system you set up, or trace the changes in the .config and .local/share directories. No simple config file which can be copied or edited with a script. But I guess that’s the price to pay for the modern experience.
What about it?
What implications for security you think it may have?
I usually have a password-protected login on my machines. Autologin opens the system up for all to see (maybe a thief, or whoever wants to snoop). There’s an Arch wiki workaround to have a password-protected screensaver kick in right after login, but I don’t know if this works with Wayland.
To be honest, I am not following your trail of thought or what you want to achieve at this stage.
Why would you want to enable Autologin for mounting the removable device automatically at login according to the screenshot above?
For all intent and purpose, I think I may have truly misunderstood your intention and thereby not being able to provide any relevant input so I withdraw from this thread.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
