Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use BindsTo dependency for mounting Removable storage devices (i.e USB) #1359

Open
RushingAlien opened this issue Mar 6, 2025 · 3 comments · May be fixed by RushingAlien/udisks#1 or #1361
Open

Use BindsTo dependency for mounting Removable storage devices (i.e USB) #1359

RushingAlien opened this issue Mar 6, 2025 · 3 comments · May be fixed by RushingAlien/udisks#1 or #1361

Comments

@RushingAlien
Copy link

RushingAlien commented Mar 6, 2025

Description

Currently mount units has a Requires dependency against the block device or backing file specified under What. This is not desirable for usecases where backing file or block device can be easily detached, which may cause lingering mounts on some filesystems (i.e BTRFS). Examples are USB storage, NBDs, and loop devices.

I have seen this myself because I use BTRFS for my USB drive, where accidental detaching causes a lingering mount.

Stuff outside of fstab are given ephemeral mount units and as I am aware has no way to set a BindsTo directive other than mounting via systemd-mount. Or by adding mount unit overrides.

For stuff in fstab you can use x-systemd.device-bound in the mount option.

Desired Outcome

For udisks to mount usb devices with a BindsTo relationship against the block device.

Note on Lingering Mounts

Not all filesystems are susceptible to lingering mounts
filesytems susceptible to lingering mounts (mounted, but block device is disconnected)

  • btrfs
  • any filesystem using nbd

I believe there are more, but those are just the ones I know.

Related

systemd/systemd#36634
https://www.freedesktop.org/software/systemd/man/latest/systemd.mount.html
https://www.freedesktop.org/software/systemd/man/latest/systemd-mount.html

@RushingAlien
Copy link
Author

RushingAlien commented Mar 6, 2025

Not all filesystems are susceptible to lingering mounts
filesytems susceptible to lingering mounts (mounted, but block device is disconnected)

  • btrfs
  • any filesystem using nbd

Now that i think about it, since this is on a filesytem case, I think udisks should just have x-systemd.device-bound as a default mount option for offending filesystems, like btrfs, so we should have a mega list of affected filesystems.

I've set x-systemd.device-bound for btrfs in my /etc/udisks2/mount-options.conf

RushingAlien added a commit to RushingAlien/udisks that referenced this issue Mar 6, 2025
Btrfs has an issue where mount can linger after a sudden device disconnect, this is very apparent with USB storage. the psuedo mount option x-systemd.device-bound overrides the default `Requires` dependency to that of `BindsTo` which will automatically stop the mount if the device became inactive. 

Partly fixes storaged-project#1359

Please list more filesystems susceptible to lingering mounts in storaged-project#1359 so they can be covered as well.
@RushingAlien
Copy link
Author

systemd/systemd#36634 (comment)

Oh perhaps udisks could use systemd-mount --discover probing? It can probe if the backing device is a removable storage, and applies a BindsTo dependency against said backing dev for the mount unit.

@RushingAlien RushingAlien changed the title Use BindsTo dependency for mounting USB storage devices Use BindsTo dependency for mounting Removable storage devices (i.e USB) Mar 6, 2025
@tbzatek
Copy link
Member

tbzatek commented Mar 7, 2025

Cleaning up lingering mounts after its backing block device disappears is done in the UDisksState cleanup thread. If that doesn't work, it should be fixed. UDisks doesn't interact with an init system regarding mounts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants