Page 1 of 2
Accessing APFS drives?
Posted: Tue Oct 29, 2024 1:43 pm
by pax-eterna
Do I need to install APFS-Fuse?
Just need to access some files on an APFS USB drive, and MX (latest AHS version) does not recognise it as a valid device.
Re: Accessing APFS drives?
Posted: Tue Oct 29, 2024 2:10 pm
by timkb4cq
Either APFS-fuse or apfs-dkms
apfs-fuse is a userland read-only option. apfs-dkms is a kernel module which has reverse engineered write capability as well reading but that part is still experimental and not yet trustworthy.
The apfs-dkms version in debian bookworm is pretty far behind (3.0 vs the current 3.11). I'm going to try backporting the latest from Trixie.
Re: Accessing APFS drives?
Posted: Tue Oct 29, 2024 2:15 pm
by pax-eterna
timkb4cq wrote: Tue Oct 29, 2024 2:10 pm
Either APFS-fuse or apfs-dkms
apfs-fuse is a userland read-only option. apfs-dkms is a kernel module which has reverse engineered write capability as well reading but that part is still experimental and not yet trustworthy.
The apfs-dkms version in debian bookworm is pretty far behind (3.0 vs the current 3.11). I'm going to try backporting the latest from Trixie.
Cool, thanks - should I wait for a while? Or safe to go ahead and install apfs-dkms?
Re: Accessing APFS drives?
Posted: Tue Oct 29, 2024 3:06 pm
by timkb4cq
I just uploaded apfs-dkms 3.11 to the MX-23 Test repo.
I'd wait a little while, especially if you have a kernel > 6.1 which was the latest supported by 3.0. The 3.11 version works up through 6.11 kernels.
Since you didn't include your QSI, I don't know what mirror you use. mxrepo.com has it now and the *.mxrepo.com mirrors will have it in 10-15 minutes. Third party mirrors update on their own schedules after that. You'll find it in the MX Test Repo tab of the MX Package Installer.
Re: Accessing APFS drives?
Posted: Tue Oct 29, 2024 3:10 pm
by pax-eterna
timkb4cq wrote: Tue Oct 29, 2024 3:06 pm
I just uploaded apfs-dkms 3.11 to the MX-23 Test repo.
I'd wait a little while, especially if you have a kernel > 6.1 which was the latest supported by 3.0. The 3.11 version works up through 6.11 kernels.
Since you didn't include your QSI, I don't know what mirror you use. mxrepo.com has it now and the *.mxrepo.com mirrors will have it in 10-15 minutes. Third party mirrors update on their own schedules after that. You'll find it in the
MX Test Repo tab of the MX Package Installer.
lovely thanks!
Off to work so I will leave it for a few hours...
Sorry re no QSI, didn't realise I needed to paste for this type of question.
Re: Accessing APFS drives?
Posted: Wed Oct 30, 2024 4:43 am
by m_pav
timkb4cq wrote: Tue Oct 29, 2024 3:06 pm
I just uploaded apfs-dkms 3.11 to the MX-23 Test repo.
Installer seems to do its job, modprobe shows apfs module is loaded after a reboot, but no joy getting my TimeMachine backup drive to mount.
fdisk -l
Code: Select all
Device Start End Sectors Size Type
/dev/sdg1 2048 422952959 422950912 201.7G Apple APFS
/dev/sdg2 422952960 488396799 65443840 31.2G Linux filesystem
lsmod |grep apfs
Code: Select all
apfs 270336 0
libcrc32c 12288 6 nf_conntrack,apfs,btrfs,nf_tables,xfs,raid456
$ sudo mount -t apfs /dev/sdg1 /media/michael/apfs/
Code: Select all
mount: /media/michael/apfs: wrong fs type, bad option, bad superblock on /dev/sdg1, missing codepage or helper program, or other error.
dmesg for info
Code: Select all
[ 1136.640140] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.
[ 1359.653215] APFS (800061g): experimental writes disabled to avoid data loss
[ 1359.653218] APFS (800061g): if you really want them, check the README
[ 1359.653220] APFS (800061g): requested volume does not exist (apfs_map_volume_super:471)
Found on Stack Exchange
This isn’t an “alarm”, it’s just a message indicating that the TOMOYO Linux MAC subsystem wasn’t activated, because user-space activation was configured but /sbin/tomoyo-init wasn’t available.
Install tomoyo-tools 2.61-20210910-1+b1 and attempting a mount only removes the first line
dmseg for info
Code: Select all
[ 2038.614251] APFS (800061g): experimental writes disabled to avoid data loss
[ 2038.614255] APFS (800061g): if you really want them, check the README
[ 2038.614256] APFS (800061g): requested volume does not exist (apfs_map_volume_super:471)
Re: Accessing APFS drives?
Posted: Wed Oct 30, 2024 1:42 pm
by timkb4cq
Have you tried mounting without the
?
The
Readme in their github doesn't show that option.
Re: Accessing APFS drives?
Posted: Wed Oct 30, 2024 2:14 pm
by m_pav
timkb4cq wrote: Wed Oct 30, 2024 1:42 pm
Have you tried mounting without the
?
Yes, that was always my first attempt, as well as just clicking the drive when it shows up in Thunar, but I didn't see the point in attaching screenshots when terminal is faster and easier. I haven;t tried accessing an internal drive yet.
I do have a MacBook Air I keep on hand for when customers have mac issues and the Time machine gives me a way to run another machine by booting from it because their controller-less SSD's make for difficulty when trying to recover something. Typical <bleep> Apple, if there's a way to make servicing anything from harder to nigh on impossible, you can trust Apple to make a freak-show out of it

Re: Accessing APFS drives?
Posted: Wed Oct 30, 2024 8:14 pm
by m_pav
Aha, my Time Machine drive was encrypted. Reformatted it as unencrypted APFS (case sensitive), making a new TimeMachine Backup and will test when it's done. Even with a SSD, TimeMachine takes eons to complete. Check back later.
Re: Accessing APFS drives?
Posted: Wed Oct 30, 2024 10:02 pm
by m_pav
Yeah, still no dice here.
Code: Select all
[60341.223096] APFS (800061g): experimental writes disabled to avoid data loss
[60341.223101] APFS (800061g): if you really want them, check the README
[60341.223103] APFS (800061g): requested volume does not exist (apfs_map_volume_super:471)
mount attempt from Thunar
The package apfds-dkms pulls in libfsapfs-utils 20201107-1+b3 as a dependency and it looks like it's had no updates since then so it's just a week off being 4 years old. Looking at the 2 most appropriate files fsapfsinfo and fsapfsmount;
# fsapfsinfo /dev/sdg1
Code: Select all
fsapfsinfo 20201107
Apple File System (APFS) information:
Container information:
Identifier : bd87d056-0147-4e2c-9565-25845aae92c5
Number of volumes : 1
Unable to print container information.
libfsapfs_container_get_volume_by_index: unable to retrieve object map descriptor for volume object identifier: 0.
info_handle_get_volume_by_index: unable to retrieve volume: 0.
info_handle_container_fprint: unable to retrieve volume: 0.
Looks like this is where the breakdown is happening. If it can not read the appropriate container index descriptor, then fsapfsmount will not be able to mount the partition, as we see below
sudo fsapfsmount /dev/sdg1 /media/michael/apfs
Code: Select all
fsapfsmount 20201107
Unable to open source container
libfsapfs_container_get_volume_by_index: unable to retrieve object map descriptor for volume object identifier: 0.
mount_handle_get_volume_by_index: unable to retrieve volume: 0.
mount_handle_open: unable to retrieve volume: 0.