Bind mount handling suboptimal

[bugreporter42]

udisks doesn't seem to provide a way to figure out the mountpoint of block devices, since it only provides an alphabetically sorted list of mounts, which includes bind mounts. Both Gnome and KDE 5 don't work properly.

# dd if=/dev/zero of=/test-disk bs=1024 count=100000
# mkdir /mnt/test-disk
# mkfs.ext4 /test-disk
# mount -o loop /test-disk /mnt/test-disk/
# mkdir /mnt/test-disk/aaa
# mkdir /mnt/aaa
# mount --bind /mnt/test-disk/aaa/ /mnt/aaa 
# udisksctl dump
... 
 org.freedesktop.UDisks2.Filesystem:
    MountPoints: /mnt/aaa
                 /mnt/test-disk

Both KDE 5 (Dolphin) and Gnome (gnome-disks) show 'test-disk' mounted under '/mnt/aaa' (they just pick the first reported mount point).

KDE bug report: https://bugs.kde.org/show_bug.cgi?id=349617

[vpodzime]

Any suggestions for a possible solution? There are definitely many ways, but I'm not quite sure what would be a preferred one.Maybe put the bind mounts aside into a separate property?

[sybrenstuvel]

Maybe put the bind mounts aside into a separate property?

I think that would be a nice solution, since it would automatically make Gnome and KDE (and other user software) pick the actual mount point.

[ondrejholy]

One of the relevant gnome bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=782814

We need definitely a way to distinguish the regular mount points from bind mounts. It would also be nice to have available bind mount roots...

[vojtechtrefny]

This might actually be quite hard to implement -- it is not possible to check if a mountpoint is "normal" or "bind".

See this comment for more information: https://bugzilla.gnome.org/show_bug.cgi?id=782814#c30

[ondrejholy]

The same problem is with btrfs subvolumes. Yes, we can't detect bind mounts, but we can find fs root e.g. over mnt_fs_get_root. It returns something else than "/" for bind mounts (which points to subdirectory - the problematic ones) and btrfs subvolumes...

[ondrejholy]

Also, handling of multiple mountpoints itself is suboptimal, because you can't choose which mountpoint will be unmounted... and seems that just one of those is going to be unmounted if Unmount method is called.

[tbzatek]

The new kernel mount API might be of some help perhaps...