You are not logged in.
I got a dump of a complete Apple MacBook Air system disk, and I’m trying to access it through the ‘udisksctl’ utility, so I can read its contents. It mostly works—I installed the “apfs-dkms” package to support the APFS Apple filesystem.
There’s one little snag that I’m running into, however, in that the ‘udisksctl’ utility runs into an error when I attempt to unmount the APFS filesystem; the standard ‘umount’ command, on the other hand, will successfully unmount the filesystem.
I think I understand the cause of the problem; it looks like ‘udisksctl’ doesn’t record the mount point of a filesystem that doesn’t have a label; when it is subsequently instructed to unmount the filesystem, it thinks it wasn’t mounted in the first place, and consequently won’t unmount it. I have no idea how to get this issue resolved, however.
Just to illustrate the issue, the remainder of this post will explain what I’m doing, and where exactly it goes wrong.
The dump file is called ‘APPLE_SSD_SM0128.DMP’; I first associate a loop device with the file:
$ /usr/bin/udisksctl loop-setup --read-only --file APPLE_SSD_SM0128.DMP
Mapped file APPLE_SSD_SM0128.DMP as /dev/loop0.Since I will be running this in a script, I want to catch the name of the loop device into a variable; the ‘losetup’ utility will eventually help me out here:
$ /sbin/losetup --output NAME,BACK-FILE --associated APPLE_SSD_SM0128.DMP
NAME BACK-FILE
/dev/loop0 /mnt/local/Legacy/Apple MacBook Air/APPLE_SSD_SM0128.DMPNext, I list the partitions that are present in the dump file:
$ /bin/lsblk --output TYPE,PATH,FSTYPE,LABEL,MOUNTPOINT --list /dev/loop0
TYPE PATH FSTYPE LABEL MOUNTPOINT
loop /dev/loop0
part /dev/loop0p1 vfat EFI
part /dev/loop0p2 apfsI can mount the first partition alright:
$ /usr/bin/udisksctl mount --block-device /dev/loop0p1
Mounted /dev/loop0p1 at /media/luvr/EFIIf I list the partitions again, then I can clearly see the mountpoint:
$ /bin/lsblk --output TYPE,PATH,FSTYPE,LABEL,MOUNTPOINT --list /dev/loop0
TYPE PATH FSTYPE LABEL MOUNTPOINT
loop /dev/loop0
part /dev/loop0p1 vfat EFI /media/luvr/EFI
part /dev/loop0p2 apfsThe partition will unmount cleanly as well:
$ /usr/bin/udisksctl unmount --block-device /dev/loop0p1
Unmounted /dev/loop0p1.Now it’s time to try the same with the second partition on the dump file:
$ /usr/bin/udisksctl mount --block-device /dev/loop0p2
Mounted /dev/loop0p2 at /media/luvr/2a0db02b-d459-4583-a12f-f83c395bfe6d
$ /bin/lsblk --output TYPE,PATH,FSTYPE,LABEL,MOUNTPOINT --list /dev/loop0
TYPE PATH FSTYPE LABEL MOUNTPOINT
loop /dev/loop0
part /dev/loop0p1 vfat EFI
part /dev/loop0p2 apfs /media/luvr/2a0db02b-d459-4583-a12f-f83c395bfe6dSo far, so good; so, let’s unmount again:
$ /usr/bin/udisksctl unmount --block-device /dev/loop0p2
Error unmounting /dev/loop0p2: GDBus.Error:org.freedesktop.UDisks2.Error.NotMounted: Device `/dev/loop0p2' is not mountedHmmm… That does not seem to work.
What does work, is the ‘umount’ command:
$ sudo umount /dev/loop0p2
[sudo] password for root:After this, I can clean up and break the association between the loop device and the dump file:
$ /usr/bin/udisksctl loop-delete --block-device /dev/loop0Where does the ‘udisksctl’ Utility go wrong?
After some further investigation, I believe that ‘udisksctl’ won’t record the mount point of a partition for which no label was set. Indeed, when the first partition—which has its filesystem label set to “EFI”—is mounted, its info, as reported by the ‘udisksctl’ utility will correctly report the mountpoint (see the “MountPoints:” line below):
$ /usr/bin/udisksctl info --block-device /dev/loop0p1
/org/freedesktop/UDisks2/block_devices/loop0p1:
org.freedesktop.UDisks2.Block:
.
.
.
org.freedesktop.UDisks2.Filesystem:
MountPoints: /media/luvr/EFI
Size: 0
org.freedesktop.UDisks2.Partition:
.
.
.When, on the other hand, the second partition—which has no label assigned to it—is mounted, the mountpoint, as reported by the ‘udisksctl’ utility, will remain blank (again, see the “MountPoints:” line below—the value is missing):
$ /usr/bin/udisksctl info --block-device /dev/loop0p2
/org/freedesktop/UDisks2/block_devices/loop0p2:
org.freedesktop.UDisks2.Block:
.
.
.
org.freedesktop.UDisks2.Filesystem:
MountPoints:
Size: 0
org.freedesktop.UDisks2.Partition:
.
.
.This looks like a fairly small error in the code—at least for someone who can make sense of it; I’m afraid, though, that I’m not such a “someone”. ![]()
Offline
https://github.com/storaged-project/udisks/issues/548
You should probably report it to upstream. I am positive it has nothing to do with labels. If a filesystem lacks a label, udisks uses UUID instead and it works for "traditional" linux filesystems like ext, btrfs, vfat etc. Could be some bug in the mounting routine.
Not related to your question, but if you only want read-only access, as a temporary measure, save it somewhere as a root owned file and just use losetup/mount directly via sudo/doas/etc. Like sudo /usr/local/bin/mount-umount-ssd.sh mount.
Offline
I can confirm that the issue is not with labels, at least not that alone. Perhaps it's a combination of label and apfs, or even just an issue with apfs.
I did a file-based loopback device, with vfat and ext and swap partitions. None of them have lables, but udisksctl worked properly on them all (except swap which won't mount).
The vfat partition:
udisksctl info --block-device /dev/loop0p1
/org/freedesktop/UDisks2/block_devices/loop0p1:
...
org.freedesktop.UDisks2.Filesystem:
MountPoints: /media/tempo/D5A1-A960
Size: 0
...One of the ext4 partitions:
udisksctl info --block-device /dev/loop0p2
/org/freedesktop/UDisks2/block_devices/loop0p2:
...
org.freedesktop.UDisks2.Filesystem:
MountPoints: /media/tempo/fa4de3c0-b3c5-4352-81c6-f3447ad475c6
Size: 5626658816
...In all of these cases, udisksctl unmount worked.
Offline
I can confirm that the issue is not with labels, at least not that alone. Perhaps it's a combination of label and apfs, or even just an issue with apfs.
I have just done a test with a file-based loopback device with two ext4 partitions—one with a label, and one without, and you’re right: both will mount and unmount properly.
So, apparently something goes wrong with APFS; unfortunately, I have no access to a labelled APFS partition, hence I cannot test that combination.
You should probably report it to upstream.
I wouldn’t mind doing so, but I don’t have a GitHub account; I’m reluctant to creating one, after I have cleaned up a whole range of accounts on various web sites.
Offline