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

Code: Select all

-t apfs
?
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

Code: Select all

-t apfs
?
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
Image

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.