Anyhow, i have just installed a Debian 13 (trixie) system, to test the ‘apfs-dkms’ package and to try and reproduce the problem under Debian proper.

Result: Under Debian 13, mounting and unmounting an APFS partition on a disk dump file using the ‘udisksctl’ utility works fine; I presume, then, that under Devuan 6 (excalibur), it will also work (since that is based on Debian 13). I therefore consider the problem solved.

P.S.: I don't really like Debian 13 (trixie), since it won’t let me remove GRUB without installing ‘systemd-boot’. Who came up with that idea? I want neither GRUB, nor systemd-boot, since I don’t want Debian (or any other system, for that matter) to mess with my EFI System Partition; I'm prepared to clean up the ESP right after a system (e.g., Devuan) insists on setting up GRUB upon initial install, but after that, it should leave my ESP alone; ‘systemd-boot’ in particular is pretty aggressive in that regard, in that it wipes away my /boot/efi/EFI/BOOT/BOOTX64.EFI (as provided by Limine) and replaces it with its own version. YUCK!

I’ll simply dump Debian and replace it with Devuan 6; I already installed it once on an Apple MacBook Air, and it appears to be well-behaved.

UPDATE: I have just tested the ‘udisksctl’ utility to mount and unmount an APFS partition under Devuan 6 (excalibur) and, as expected, it works fine. Problem definitely solved!

UPDATE—QUICK (admittedly, off-topic) NOTE: Even though, by default, Debian 13 (trixie) wouldn’t let me remove GRUB without installing ‘systemd-boot’, I eventually succeeded in avoiding having either boot loader on the system. All I had to do, was to purge the ‘shim-signed’ package first:

# apt purge shim-signed
The following packages were automatically installed and are no longer required:
  mokutil  shim-helpers-amd64-signed  shim-signed-common  shim-unsigned
Use 'apt autoremove' to remove them.

REMOVING:
  shim-signed*

Summary:
  Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
  Freed space: 1,068 kB

Continue? [Y/n] Y
(Reading database ... 110520 files and directories currently installed.)
Removing shim-signed:amd64 (1.51~1+deb13u1+16.1-2~deb13u1) ...
Installing for x86_64-efi platform.
Installation finished. No error reported.
No DKMS packages installed: not changing Secure Boot validation state.
(Reading database ... 110516 files and directories currently installed.)
Purging configuration files for shim-signed:amd64 (1.51~1+deb13u1+16.1-2~deb13u1) ...
Installing for x86_64-efi platform.
Installation finished. No error reported.
No DKMS packages installed: not changing Secure Boot validation state.

(I have no use for ‘shim-signed’, since I have “Secure” Restricted Boot disabled.)

I then also ran the auto-removal step that the output of the above command suggested:

# apt --purge autoremove
REMOVING:
  mokutil*  shim-helpers-amd64-signed*  shim-signed-common*  shim-unsigned*

Summary:
  Upgrading: 0, Installing: 0, Removing: 4, Not Upgrading: 0
  Freed space: 3,190 kB

Continue? [Y/n] Y
(Reading database ... 110516 files and directories currently installed.)
Removing shim-signed-common (1.51~1+deb13u1+16.1-2~deb13u1) ...
Removing mokutil (0.7.2-1) ...
Removing shim-helpers-amd64-signed (1+16.1+2~deb13u1) ...
Removing shim-unsigned:amd64 (16.1-2~deb13u1) ...
Processing triggers for man-db (2.13.1-1) ...
(Reading database ... 110490 files and directories currently installed.)
Purging configuration files for shim-signed-common (1.51~1+deb13u1+16.1-2~deb13u1) ...
Purging configuration files for shim-helpers-amd64-signed (1+16.1+2~deb13u1) ...

I could subsequently remove GRUB:

# apt purge --allow-remove-essential 'grub*'
.
.
.
The following packages were automatically installed and are no longer required:
  efibootmgr  libefiboot1t64  libefivar1t64
Use 'apt autoremove' to remove them.

REMOVING:
  grub-common*  grub-efi-amd64*  grub-efi-amd64-bin*  grub-efi-amd64-signed*  grub-efi-amd64-unsigned*  grub2-common*  os-prober*

WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  grub-efi-amd64-signed  grub-common (due to grub-efi-amd64-signed)

Summary:
  Upgrading: 0, Installing: 0, Removing: 7, Not Upgrading: 0
  Freed space: 42.6 MB

Continue? [Y/n] Y
(Reading database ... 110490 files and directories currently installed.)
Removing os-prober (1.83) ...
dpkg: warning: while removing os-prober, directory '/var/lib/os-prober' not empty so not removed
Removing grub-efi-amd64 (2.12-9+deb13u2) ...
Removing grub2-common (2.12-9+deb13u2) ...
Removing grub-efi-amd64-bin (2.12-9+deb13u2) ...
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: this is a protected package; it should not be removed
Removing grub-efi-amd64-signed (1+2.12+9+deb13u2) ...
Removing grub-efi-amd64-unsigned (2.12-9+deb13u2) ...
Removing grub-common (2.12-9+deb13u2) ...
Processing triggers for man-db (2.13.1-1) ...
(Reading database ... 109977 files and directories currently installed.)
Purging configuration files for grub2-common (2.12-9+deb13u2) ...
Purging configuration files for grub-common (2.12-9+deb13u2) ...
dpkg: warning: while removing grub-common, directory '/var/lib/grub/ucf' not empty so not removed
Purging configuration files for grub-efi-amd64 (2.12-9+deb13u2) ...
Purging configuration files for grub-efi-amd64-bin (2.12-9+deb13u2) ...

Afterwards, I did a bit of cleanup:

• Reviewed the warnings, i.e., checked and deleted directories ‘/var/lib/os-prober’ and ‘/var/lib/grub/ucf’ (after which  ‘/var/lib/grub’ could also be deleted);

• Marked ‘efibootmgr’ as manually installed—after which no packages remained to be auto-removed;

• Ran ‘efibootmgr’ to clean up the EFI Boot Menu;

• Cleaned up the ESP (“EFI System Partition”), i.e., deleted its ‘debian’ subdirectory;

• Cleaned up the  ‘/boot’ directory, i.e., deleted its ‘grub’ subdirectory.

Done!

No github is required to report bugs - that's what reportbug is for.  I think you'll want to use -B debian since udisks2 is not a forked package.

You mean, I could report this to Debian from this Devuan system?

Alternatively, I could install an up-to-date Debian system, and report it from there; I have been thinking of giving Debian another try anyway. Would that be more efficient, or wouldn’t it really matter?

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