Timeline for Removable media mounting strategies
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 6 at 1:06 | comment | added | jungle_jim | Tom, Your preferred approach is what I ended up going with. I tried udev rules and fstab entries, on their own, and tested how each functioned separately and together. That really helped me drive home the point of what they're doing and demonstrate how it all interacts. Updating my fstab to use the "x-systemd.automount" and subsequent options like you said works exactly as I was hoping. thanks! | |
| Oct 6 at 1:03 | vote | accept | jungle_jim | ||
| Oct 3 at 19:51 | comment | added | jungle_jim | (cont) Your preferred approach for a "likely to be inserted" drive (or in my case a single port, like a single micro SD socket, limited by hardware) as an fstab entry is something I came across previously but will continue to read up on. I've also come to understand mount/automount units a bit better now as well so all of this is starting to click and I'm seeing more how they interact with one another and have trade-offs. Thanks for the feedback! | |
| Oct 3 at 19:48 | comment | added | jungle_jim | totally understandable in the broader implementation of a linux OS, thanks! In my particular application, there are some downstream restrictions which let me get away with it but that wasn't mentioned in my OP. In addition as well, I understand how specifying a particular UUID to help avoid that stacking effect limits it to just the one specific piece of hardware (and that can change too!), which doesn't implement well for a generic "access any drive that's mounted". (cont) | |
| Oct 3 at 19:05 | comment | added | Tom Yan | @jungle_jim The problem with the udev rule approach is that it is not "flexible", unless you just need it for one / a few specific drives / filesystem. For example, you'll need to make sure the rule matches with only one specific card / slot / filesystem, otherwise multiple filesystems would get "stack-mounted" on the same mountpoint. And even if you don't hardcode the mountpoint as something like /mnt/uSD (but use something like /mnt/%k), it still won't work very well unless the mount options you specify is suitable for every potential target. | |
| Oct 3 at 17:35 | comment | added | jungle_jim | Last thing was, could you expand on your final statement of using udev to mount on insertion? In the OP I didn't elaborate super far but my intended use-case would be on a system with a micro SD slot where users are able to insert/remove for a local file access type thing. Basically, I'm trying to understand/replicate what that "front end" of GNOME/PCManFS is accomplishing. It seemed like from my searching that's what a udev rule would be well suited for but, again, on a learning journey. thanks! | |
| Oct 3 at 17:28 | comment | added | jungle_jim | As mentioned, I'm working headless but I should have specific headless without any kind of UI (so just straight CLI, no UI environment), which is the other reason why I was diving into this. I'm familiar with GNOME's ability or the piOS equivalent (uses PCManFS) to do the same thing; provides options for auto-mounting options/preferences. I haven't dug into these to see if they also function outside of a UI environment but that is the reason why i was looking at the more "simple" implementations. For sure have udisks2 on the list as mentioned though! | |
| Oct 3 at 17:24 | comment | added | jungle_jim | Great clarification on the "automount" nomenclature. In my reading I had come across that it's typically the specified term for removable media vs persistent physical devices. I had also come across as you mentioned that it's an on-demand specific keyword (vs "mount") but the addition detail is good. | |
| Oct 3 at 16:04 | history | answered | Tom Yan | CC BY-SA 4.0 |