Usb Automount creating extra folders

[dTanks]

In our application, we use USBs to store extra user data, and also to sometimes to transfer data. The current implementation inside of Torizon v7.2 seems to sometimes not delete the previous folders it created on reboot (power loss) and instead keeps creating new folders to mount USBs to.

I have done a little bit of research, and it seems like Torizon is using Udisks2 to do their auto-mounting, and its a somewhat common problem for it to change the mounting location of USBs over time. I tried disabling Udisks2, and adding a u-dev rule for adding usbs on another board (we had used this before on our solution before moving to Torizon), but the rule seems to not be triggering on bootup.

Is there any clear guidance on how to solve this issue? I don’t mind editing our logic to search additional folders to find where the USB is mounted, but it seems to occur between 10-20% of reboots, and over a couple years I am imaging hundreds of folders being created, which isn’t ideal.

I am not sure why the u-dev rule we have used before isn’t triggering on reboot, and if I perhaps missed a setting. The rule works when plugging in a USB after boot, but is not triggering on USBs that are present on bootup. The rule (which just calls a script that handles mounting the USB), is shown below. The script is a bit heavy handed and proceeds to delete folders that exist where I normally mount, but this is ok in our application, as long as it makes sure the USB is mounted to the correct location.

ENV{ID_FS_LABEL_ENC}==“?*”, ACTION==“add”, SUBSYSTEMS==“usb”,
RUN+=“/config/systemd/udev-automounter.sh %k”

ENV{ID_FS_LABEL_ENC}==“?*”, ACTION==“remove”, SUBSYSTEMS==“usb”,
RUN+=“/config/systemd/udev-autounmounter.sh %k”

ENV{ID_FS_UUID}==“?*”, ACTION==“add”, SUBSYSTEMS==“usb”,
RUN+=“/config/systemd/udev-automounter.sh %k”

ENV{ID_FS_UUID}==“?*”, ACTION==“remove”, SUBSYSTEMS==“usb”,
RUN+=“/config/systemd/udev-autounmounter.sh %k”

Also attached is the example file proliferation from udisks2 after about 10 reboots (in our case, reboots are from power loss to the board)

[ToradexAI]

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer?

---

Hello, and thank you for your detailed question!

Your analysis is correct—Torizon uses udisks2 for USB auto-mounting, and it can indeed create multiple mount-point folders if not properly cleaned up, particularly after abrupt power losses. The issue with folders accumulating comes from udisks2’s design: when it detects what it thinks is a still-busy mount-point, it adds a numeric suffix to avoid conflicts, which, as you’ve noticed, can get out of hand over time.

Addressing Folder Proliferation with udisks2

If you want to continue using udisks2, the best mitigation is to programmatically find which path is actually mounted at runtime, but as you highlighted, that doesn’t prevent the proliferation issue itself.

Alternative: Custom udev Rule Approach

Switching to your own custom udev mounting is a valid solution. However, the behavior you’re seeing—your udev rule only firing on hotplugs, not on devices present at boot—is a classic quirk of udev. During boot, devices present may be handled before your udev rules are fully set up or before all conditions (like the USB subsystem initialization) are met.

Here are practical suggestions, based both on community experience and Linux best practices:

1. Ensure udisks2 is Fully Disabled

Make sure udisks2 isn’t running or interfering:

systemctl disable --now udisks2.service

This step is crucial before implementing your own automounting method.

2. udev Rule Limitations & Workarounds

Issue: udev rules may not fire for devices present at boot.

Workaround:

• Write a systemd service that, on startup, scans for attached USB storage devices and runs your mount script manually.
  • This complements your udev rule, which can continue to handle hotplug events.

Example systemd Service (usb-mount-at-boot.service):

[Unit]
Description=Scan and mount USB drives at boot
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/scan-and-mount-usb.sh

[Install]
WantedBy=multi-user.target

Example scan-and-mount-usb.sh:

#!/bin/sh
for dev in /dev/sd*[1-9]; do
    /config/systemd/udev-automounter.sh $(basename $dev)
done

• Make this script executable and enable the service:

chmod +x /usr/local/bin/scan-and-mount-usb.sh
systemctl enable usb-mount-at-boot.service

3. Managing Mount Points

To avoid folder proliferation:

• Always mount to a predictable folder (e.g., /media/usb1).
• Before mounting, your script should ensure the directory exists, and that it’s not already in use or mount-point-stale:
  • Use umount and rmdir carefully to clean up before re-mounting.

4. Alternative: Use /etc/fstab for Persistent Mounts

If your USBs always have the same label/UUID and you want the mount-point to be consistent, you can set static mount points using /etc/fstab. For USB sticks with unique labels, you can even create multiple entries.

Example fstab entry:

UUID=YOUR-USB-UUID  /media/usb1  auto  defaults,nofail  0  0

This approach prevents directory proliferation but is less dynamic; it is best when USBs are semi-permanent.

---

Additional Pointers from Community Discussion:

• One reported solution is to use udev rules that spawn a script, but only after verifying the mount directory exists (discussion).
• Automounting with udev can miss drives present at boot, and such drives may need to be handled by an init script or systemd unit as described above.

In summary:

• Disable udisks2 if rolling your own automount solution.
• Use udev for hotplug, and a systemd service for boot-time scanning/mounting.
• Clean up and mount to dedicated static directories to avoid folder proliferation.

Let me know if you’d like help formatting any of these scripts or services specifically for your use-case!

Best regards,
Toradex AI Assistant.

[jeremias.tx]

The current implementation inside of Torizon v7.2 seems to sometimes not delete the previous folders it created on reboot (power loss) and instead keeps creating new folders to mount USBs to.

Interesting, I’ve never actually seen this behavior myself, nor have I seen it reported by others using Torizon OS. That said some searching online seems to support what you said. I’ve seen a few threads on Github where others have described this behavior with Udisks2 as well.

Now for the actual issue. I tried to see if I could reproduce this myself to try and analyze the issue more closely. I did 20+ boot cycles on my device and did not see the issue occur. I only ever had the 1 mount folder appear. Perhaps I was just unlucky, or maybe there are some unknown factors that increase the chances of this happening.

In any case, as for your udev rule approach. I’m not entirely sure why your rules aren’t triggering on boot. Could be due to how udev treats devices present on boot versus devices attached after boot differently. I do have one idea though.

For context on Torizon OS by default we use this C program usermount this program runs as a daemon and uses Udisks2 under the hood to auto-mount devices: GitHub - tom5760/usermount: A simple C program to automatically mount removable drives using UDisks2 and D-Bus.

However, we had a similar issue where usermount only auto-mounted devices attached after boot and not devices that were already present on boot. So we created a simple bash script that runs once on boot to auto-mount devices that were present on boot. Then the usermount program would take over for devices attached after boot. You can see here how we created the systemd service to orchestrate this: meta-toradex-torizon/recipes-support/usermount/usermount at scarthgap-7.x.y · torizon/meta-toradex-torizon · GitHub

Perhaps you could do something similar as well. Create a systemd service that executes your script once on boot to handle the boot case. Then your udev rules can handle things after boot as it does currently.

Best Regards,
Jeremias