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.

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.

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.

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.

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.DMP

Next, 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 apfs

I can mount the first partition alright:

$ /usr/bin/udisksctl mount --block-device /dev/loop0p1
Mounted /dev/loop0p1 at /media/luvr/EFI

If 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 apfs

The 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-f83c395bfe6d

So 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 mounted

Hmmm… 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/loop0

Where 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”.