3

I'm working my way through understanding more about unix/linux and how the various tools/packages/options interact with one another (for example, the role of systemd, or how fstab works). I'm also trying to read/absorb/understand as much as I can about some of the "typical" or "best practice" ways of doing things, which leads me to the title of the question: removable media.

I'm testing on a headless Debian distro (rPi OS, lite) and have udev and systemd both at my disposal. The ultimate goal here is to mount and access removable media both 1) if it's present at boot and 2) if it gets inserted/removed after boot. I'm reading through various threads, stack posts, etc. and trying to absorb the various ways to do this, pitfalls/errors/bad practices to watch out for, and what a "best" way to do this would be for a robust implementation.

So far I've gotten a couple things working, separately:

  1. mounting using fstab entry at startup
  2. mounting using udev rule on insert/re-insert

The fstab entry I've successfully added mounts the block device based on its identifier of something like /dev/mmcblk[x]p[x]. Using some options like nofail and others in the fstab documentation, it will successfully find and mount the drive at boot, without holding up the system, as an "automount" or removable type.

Separately then, I've also been able to create a udev rule that leverages systemd-mount to recognize when a new block device is inserted through the "add" action. It then calls on systemd-mount to create an "automount" point.

Testing both of these (separately) I've found that the fstab entry will successfully mount at boot but not detect a "re-insert" where the device is removed and then re-inserted. Additionally, the udev rule does a great job of capturing when a new device is inserted, but does not mount it when the system boots.

The above then leads me to the root of my question; when handling removable media mounting/unmounting, what's a good "typical" or "best practice" way of handling things? Does both an fstab and udev rule need to be created to handle both cases?

Secondly, I'm not 100% sure yet I'm not missing something in a configuration/option somewhere for both of this. For example:

  • I've seen that fstab can also use systemd.[x] parameters like systemd.mount to create the "trap" for the removable media. From my understanding this will create the mount point and essentially have things ready for the media (to be inserted) but will not actually mount the device until it's accessed (or a request to access the mount point is made). However, that still seems to be only related to devices mounted at boot time and not dynamic handling of devices. This seems odd to me and makes me think I'm not understanding the capability of fstab or its interactions with the system as a whole.
  • Similarly, with the udev rule, it seems odd to me that the "add" function doesn't trigger on startup if the device is already plugged in / present. I'd expect at some point the device has to be "added" but I'm assuming it's related to a timing/availability aspect of how things are processed when the kernel is booting up and when udev is available to process rules; which is why it never sees it as an "add" truly.

Thanks for reading; couple of last things: I'm aware of the udisk2 and autofs modules which also seem to handle things like this. I'm working my way into those but would like to understand the principles those (likely) work on first, to better understand/use those tools and be successful in implementing them.

Also for completeness, these are what I currently have for the auto-mount tactics discussed above (side-note I do realize the mount permissions between them are different; this is just what I've been experimenting with thus far).

fstab entry: /mnt/mmcblk1p1 /mnt/uSD vfat auto,nofail,rw,noexec,user 0 0

udev rule: ACTION=="add",SUBSYSTEM=="block",ENV{ID_FS_USAGE}=="filesystem",RUN{program}+="/usr/bin/systemd-mount --no-block -A -G --options=rw,umask=000 %N /mnt/uSD"

Improve this question
0

1 Answer 1

Reset to default
5

First of all, I personally avoid nofail, because technically there's some kind of flaw in it (unresolved last time I checked): the mount unit would not be ordered against local-fs.target, which result in it being potentially stopped too early upon shutdown. (Although there may not be real concern as there might be other facilities to make sure the filesystems to be unmounted or at least flushed at the end, or not. Either way, my OCD hates the flaw anyway.)

My preferred alternative is x-systemd.automount with a reasonable x-systemd.device-timeout= (which is sadly for reasons not supported in "written" mount / automount units) -- if it's a filesystem / drive for which an fstab entry makes sense (e.g. the drive is likely to be plugged in).

Note that systemd "automount" has nothing to do with mounting a filesystem upon the insertion of its block device. The "auto" here means that the mountpoint would be mounted with the designated filesystem when the mountpoint is accessed. (In other words, it "delays" the mounting "until necessary".)

udisk2 itself doesn't get filesystems mounted automatically either. Essentially its purpose is to free you from fstab entries (as it will create directories under somewhere like /media/ or /run/media/$UID on demand, and allows you to leverage polkit to allow non-root user to have filesystems mounted). It also smartly adds mount options (e.g. uid=, gid=, fmask=, dmask=...) for filesystems from e.g. Windows, which do not (typically?) store any Linux (or unix or posix; whatever) ownership or permission.

What usually gets the job done is some "front-end" of udisks2, such as your desktop environment (e.g. GNOME) or udiskie. (I don't know the details behind the scene. I mean, probably the udisks2 daemon is what monitors whether there is a new filesystem, but either way, it still won't mount stuff until a "front-end" asks it to.) If you have no such "front-end" running, you can / will need to ask it with e.g. udisksctl.

Using a udev rule to get stuff mounted upon insertion doesn't make much sense to me. In my opinion one would only need / want that in some really niche case, for perhaps one or a few specific drives.

Improve this answer
7
  • 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. Commented Oct 3 at 17:24
  • 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! Commented Oct 3 at 17:28
  • 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! Commented Oct 3 at 17:35
  • 1
    @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. Commented Oct 3 at 19:05
  • 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) Commented Oct 3 at 19:48

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.