I really REALLY want to learn about UDISKS/UDISKS2 and UDEV. How do I accomplish this? My workstations are all Linux Mint 19.xx Cinnamon.
Please don't tell me to "Read The Code."

It seems that every distro has files and parts in different places and might even have some different names for things.

The man pages tell me the details of the various executable components and the configuration files: Here is a button. Push it and this happens. Where do I find explanations for why I might have interest in that button in the first place?

Internet searches offer loads of details, but I'm left to discover which edition of which package for which disto the articles present.

Distro forum search also suffer from the "which edition of {package}" confusion. The revision velocity has far outstripped my ability to read articles in real time.

Why do I want to really REALLY learn this?
I handle a large number of SD cards, thumb/key drives, and other USB connected storage. I want to implement my own controls over

• What devices get named;
• Where each device gets mounted and mount-point names;
• Notifications for events affecting each device;
• Processing that happens at device connection & mount;
• Processing that happens at device disconnect & unmount;
• Logging surrounding all of this;
• Other things I haven't thought of yet

{ASIDE}
In ancient times, there used to be a manual called "Theory of Operation," another called "Operations Manual," and another called "Administration Manual." The "Operations Manual" content was mostly like what we see in today's man pages. The "Administration Manual" covered all of the configuration, monitoring, error reporting, and fault analysis.

It is the "Theory of Operation" contents that I simply cannot find. This content explained why the application suite exists, what is supposed to accomplish expressed in the language of the business environment, described the several components of the suite and how they were connected, the interactions among the components, the interactions between the suite and the rest of the running applications.
{/ASIDE}

Thanks in advance,
~~~ 0;-Dan

I'm not certain that any one reply will contain all that you ask for, but in any case I think many would agree that the archlinux wiki pages are often a source of useful information with practical use cases (and further references listed at the bottom of the respective pages)...

https://wiki.archlinux.org/index.php/Udisks
https://wiki.archlinux.org/index.php/Udev

In general, make a thread any time you're stuck (with descriptive title) and those that can assist will provide the necessary clarification/guidance.

Hope this is enough to get you started.

1 members found this post helpful.

To answer the first part of that question with respect to automatic "udisks2/desktop" mounting for users...
udisksd communicates with desktop environments via D-BUS (org.freedesktop.UDisks2 service) about storage device related events.

If you want to know about what's going on from a user perspective, you can use the following CLI utilities

1 members found this post helpful.

I discovered use of /media/{something} instead of /media/USER/{something} but I appreciate your reply with that detail.
Like I said, I have a couple of bushels of SD cards and thumb drives -- a whole universe of makers and features and such.

• I'd really like to understand what default behavior is.
  • What determines the {something} that becomes the device mount point name?
  • What is involved to manage the several "usb hub" parts that are my workstations and port replicators and such?
• I really want to run my own script to sort out what happens for these devices.
  • Step 1 -- After the default mount happens, launch my script that will access the device at that mount point, decide if I want different, and make it available (sym link?) somewhere else. After that happens process the device at the newly created somewhere else.
  • Step 2 -- Take control as early as possible, create my own mount points, then launch my processing script(s) avoiding the dance around the default behavior.

{GRUMBLE}
I find it frustrating that the default processing for SD media and thumb drives seems hidden or otherwise hard to find. As a technical writer, I appreciate that folks are busy writing code instead of end-user/power-user documentation. It is also difficult to document code that is constantly evolving for better or worse.

I also find it frustrating that it appears that the choice or /media/USER/{something} and its derivatives were hard-coded into the utilities rather than some configuration detail.
{/GRUMBLE}

Thanks in advance,
~~~ 0;-Dan

If the filesystem has a volume label then that is used. You can set the label as required for each removable media volume you have if desired. IIRC, I think the UUID may be used in other situations.

For example, one of my devices shows up like this...
You'd need to write a custom udev rule to trigger such a short-lived script. This may be of interest to you...
https://unix.stackexchange.com/quest...storage-device

1 members found this post helpful.

If you trully would like to implement some other removable media mounting mechanism, you can inhibit udisks2 (assuming systemd) using
Now removable media will be ignored, and you can manually mount instead, or employ your own hand-rolled script triggered via udev/systemd. This might be enough to get you started and tweak as you like...

https://www.andreafortuna.org/2019/0...v-and-systemd/

1 members found this post helpful.

I'm a kindred spirit with the OP when it comes to the execrable state of some of the Linux documentation. This isn't first time this week (and it's only Wednesday!) that I've spent hours looking for information needed to complete something that was fairly simple to accomplish using just using the manpages a few years ago. But let's not go there.

Here's what I found works to keep USB devices from getting mounted under "/run/media/$USER/disgustingly-long-UUID" and, instead, mount them under "/media".

(NOTE: I agree with the OP that while these two locations might be great as hard-coded defaults, it should be possible to override them via a user-maintained configuration file.)

1. Create a udev rule for your device. For the Seagate Backup+ drive I use for big file transfers (giga-sneakernet that I resort to if/when the wifi on my laptop is hosed), that rule looks like:
   
   Code:

   KERNEL=="sd*", ATTRS{idVendor}=="0bc2", ATTRS{idProduct}=="a013", SYMLINK="backup-plus", MODE="0660"

2. Ferarri's tip on the "99-udisks2.rule" file moves the mount point out of that /run/media/$USER location to "/media".
   
3. When you add the udev rule for your USB device and add the 99-udisks2 rule, I bounced the udev subsystem using:
   
   Code:

   udevadm control --exit
   udevadm control --start-exec-queue
   udevadm control --reload

   In addition, I bounced the udisks2 service (via YaST but doing it via the CLI would do the same thing) but this might have been completely unnecessary.

I'm sure that some of the udevadm command sequence might have been unnecessary but it was easier than a full reboot.

Anyway... Now, when I plug in that Seagate device, it's mounted at "/media/backup-plus".

What I have not figured out is how to unmount the USB device when working from a virtual console without using sudo. The Plasma device notifier lets me unmount it without any need for extra permissions.

In the past, my device mounts were being done directly from the udev rule that defined the specific device characteristics by specifying a script in a "RUN+=scriptname" clause in the rule. That hasn't worked since systemd became more insinuated into openSUSE (worked fine through 11.x, though).

I can see the symlink name appear in the "udisksctl monitor" output when I plug in the Seagate drive that that udev rule (above) was configured for. But I fail to see the connection between what the udev rule specifies and how that becomes known to udisks2. There is a "MountPoints" record displayed by "udisksctl monitor" but it's always an empty string. So, somehow, udev and udisks2 are figuring it all out but I'm decidedly not keen on "Then a miracle occurs" type operations on my computer systems. Would it kill the developers to include a document that show a diagram of how this all works? (Linux includes some real kick-booty tools that let you create such documents, ya know. ;^) )

Cheers... Hope this get you closer to what you were looking for.

1 members found this post helpful.

You should be able to do this via udisksctl command eg
This can still be done by disabling (and masking) the udisks2.service, and using a custom systemd service + script as outlined in the post #6 if desired.

I'm not a programmer/developer, but "under the hood" communication between udisksd and udev happens via D-Bus.
http://storaged.org/doc/udisks2-api/latest/
and the 'dbus-monitor' command can be used to monitor messages going through this message bus.

I have multiple USB drives in an external enclosure that I used for daily rsyncs that are mounted via fstab (via "LABEL="). I'd hate to discover that disabling udisks2 adversely affects that mounting process. Just getting the UUIDs out of the mount points is a real boon. Using "udisksctl" in a script or, maybe, an alias will suffice for CLI work.

Heh, I've always had this sneaking suspicion that D-Bus was going to demand my attention at some time.

Thanks...

No, udisks specifically ignores devices included in /etc/fstab. Completely different mounting mechanisms. For such administrator-controlled mounts, the umount command is used (with root privileges required).

I'd love to DM/PM about documentation sometime.

Take a look at the ownership and permissions for the drive and its mount point. Then look at the authorities granted to the remote process. Lastly, look at the permissions and authorities to accoumplish mount and unmount. I've made this work in the past by creating uid/gid and Access Control Lists (ACL) for all of the parts and the user running the script at the remote. That user and the script need entries in the sudoers file.

Thanks in advance,
~~~ 0;-Dan