MX Linux Forum

Posted: **Tue Oct 29, 2024 1:43 pm**

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.

Posted: **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.

Posted: **Tue Oct 29, 2024 2:15 pm**

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?

Posted: **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.

Posted: **Tue Oct 29, 2024 3:10 pm**

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.

Posted: **Wed Oct 30, 2024 4:43 am**

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)

Posted: **Wed Oct 30, 2024 1:42 pm**

Have you tried mounting without the

Code: Select all

-t apfs

?
The Readme in their github doesn't show that option.

Posted: **Wed Oct 30, 2024 2:14 pm**

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

Posted: **Wed Oct 30, 2024 8:14 pm**

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.

Posted: **Wed Oct 30, 2024 10:02 pm**

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.

Posted: **Wed Oct 30, 2024 11:05 pm**

There is a much newer (April 2024) version in github. I'll try packaging that tomorrow.

Posted: **Thu Oct 31, 2024 1:39 am**

Thank you. I have a really full on day tomorrow so not sure when I can test it.

Here's the apt history from installing apfs-dkms

Code: Select all

2024-10-31  12:15:44  install  libfsapfs-utils                    amd64  <none>                           20201107-1+b3
2024-10-31  12:15:44  install  libfsapfs1                         amd64  <none>                           20201107-1+b3
2024-10-31  12:15:44  install  libbfio1                           amd64  <none>                           20170123-6
2024-10-30  20:55:11  install  apfs-dkms                          all    <none>                           0.3.11-1~mx23

Posted: **Fri Nov 01, 2024 6:23 pm**

libfsapfs_20240429 is now available in the MX23 Test repo. That just contains the library. The build also generates
libapfs-tools (which contains the fsapfsinfo and fsapfsmount binaries)
libfsapfs-python3
libfsapfs-dev

Posted: **Sat Nov 02, 2024 12:46 am**

I had a suspicion the issue might have been with my shrinking the drive by 32GB and placing an ext4 partition there so I could identify it from the other drives I have lying around because it's a good used SATA-SSD in an enclosure and I'm forever swapping them out for customer drives.

I made a new GUID partition table using gparted, took the unit to my Macbook Air running Monterey and reformatted it again to unencrypted APFS and dropped a few files on it. Upon inserting the USB plug into my machine running from a remastered MX-23.4 AHS Live USB with apfs-fuse installed, the drive was auto-mounted in read-only mode.

I tested this 3x further on differing setups and can confirm the combination of the apfs-fuse and the libfsapfs Tim put in Testing works to bring simple click and go read-only access to the APFS volume, with the exception, it did not work for me on an apfs formatted drive which had the apfs container reduced to provide space for an ext4 partition added.

It's highly likely that was the issue all along, but where Apple are concerned, it's always best to have the latest.

@pax-eterna just do as per the image below, install apfs-fuse and libfsapfs which should pull in libfsapfs-tools and reboot, you should have read-only access with a simple click and go through your preferred File Manager, and I recommend you stay away from experimental write access.

I will follow up within a day or 2 as I push this a little further to test its boundaries.

EDITED for clarity and to add the image

Posted: **Sat Nov 02, 2024 12:23 pm**

Thanks, will do that.

Posted: **Sun Nov 03, 2024 4:30 am**

After some experimentation I've come to the conclusion that an Apple TimeMachine backup drive is simply not going to be usable, but most any other unencrypted APFS formatted drive should be fine.

MacOS permissions are much the same as ours, in that they're unix-like, but they start with a different value, so much of the files and folders will be inaccessible to our users, evidenced by a locked file or folder icon, but they will not be off-limits to the root user. While it's easy enough to open a root instance within your preferred file manager, there is a more elegant and less frustrating method.

The default first mac user has a User ID ( UID ) value of 501 so we can simply make a group with a matching value, add ourselves to it and this will remove the restriction. This will only align permissions with the first macOS user account, but if there's more than one macOS user account you wish to access, you can easily add another, and like ours, each user is a sequential number value starting from 1000, so the second macOS users UID will be 502, and so on.

Attempting to add a Linux user with the same user name as the macOS user will not work because outside of their host OS, UNIX type user account names have no value, and we're accessing the macOS content from that position, therefore, we use a matched UID value.

Code: Select all

sudo groupadd -g 501 apfs

This will add a new UNIX group called apfs with a UID value of 501

Remember to open MX USer Manager and add yourself to the group you just created and you'll have instant access when you next mount the drive.

Posted: **Mon Jan 06, 2025 11:29 pm**

@timkb4cq @pax-eterna It's now a little over 2 months since my last post in this thread and I have found a snafu with the apfs-dkms from Testing installation - it caused the Debian 6.12.8 kernel upgrade to fail with a dkms error.

Code: Select all

Running the pre_build script:

Building module:
Cleaning build area...
make -j4 KERNELRELEASE=6.12.8-amd64 -C /lib/modules/6.12.8-amd64/build M=/var/lib/dkms/linux-apfs-rw/0.3.11/build....(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.12.8-amd64 (x86_64)
Consult /var/lib/dkms/linux-apfs-rw/0.3.11/build/make.log for more information.

I consulted the log as above but it only contained the last successful operation, so nothing to assist from there. Uninstalled the package and the kernel installation completed without error.

---- EDIT ----
Repeated on another machine and got the log file, also checked that removing the package allowed the updated kernel installation to complete. Following a reboot into the new kernel, the apfs-dkms package still failed to install.

make.log from the failed reinstallation

Code: Select all

DKMS make.log for linux-apfs-rw-0.3.11 for kernel 6.12.8-amd64 (x86_64)
Tue 07 Jan 2025 18:28:42 NZDT
make: Entering directory '/usr/src/linux-headers-6.12.8-amd64'
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/btree.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/compress.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/dir.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/extents.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/file.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/key.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/libzbitmap.o
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c: In function ‘__apfs_write_begin’:
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c:568:35: error: passing argument 1 of ‘__block_write_begin’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  568 |         err = __block_write_begin(page, pos, len, apfs_get_new_block);
      |                                   ^~~~
      |                                   |
      |                                   struct page *
In file included from /var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c:7:
/usr/src/linux-headers-6.12.8-common/include/linux/buffer_head.h:261:39: note: expected ‘struct folio *’ but argument is of type ‘struct page *’
  261 | int __block_write_begin(struct folio *folio, loff_t pos, unsigned len,
      |                         ~~~~~~~~~~~~~~^~~~~
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c: In function ‘__apfs_write_end’:
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c:631:66: error: passing argument 6 of ‘generic_write_end’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  631 |         ret = generic_write_end(file, mapping, pos, len, copied, page, fsdata);
      |                                                                  ^~~~
      |                                                                  |
      |                                                                  struct page *
/usr/src/linux-headers-6.12.8-common/include/linux/buffer_head.h:268:33: note: expected ‘struct folio *’ but argument is of type ‘struct page *’
  268 |                                 struct folio *, void *);
      |                                 ^~~~~~~~~~~~~~
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c: At top level:
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/lzfse/lzfse_decode.o
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c:701:27: error: initialization of ‘int (*)(struct file *, struct address_space *, loff_t,  unsigned int,  struct folio **, void **)’ {aka ‘int (*)(struct file *, struct address_space *, long long int,  unsigned int,  struct folio **, void **)’} from incompatible pointer type ‘int (*)(struct file *, struct address_space *, loff_t,  unsigned int,  struct page **, void **)’ {aka ‘int (*)(struct file *, struct address_space *, long long int,  unsigned int,  struct page **, void **)’} [-Werror=incompatible-pointer-types]
  701 |         .write_begin    = apfs_write_begin,
      |                           ^~~~~~~~~~~~~~~~
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c:701:27: note: (near initialization for ‘apfs_aops.write_begin’)
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c:702:27: error: initialization of ‘int (*)(struct file *, struct address_space *, loff_t,  unsigned int,  unsigned int,  struct folio *, void *)’ {aka ‘int (*)(struct file *, struct address_space *, long long int,  unsigned int,  unsigned int,  struct folio *, void *)’} from incompatible pointer type ‘int (*)(struct file *, struct address_space *, loff_t,  unsigned int,  unsigned int,  struct page *, void *)’ {aka ‘int (*)(struct file *, struct address_space *, long long int,  unsigned int,  unsigned int,  struct page *, void *)’} [-Werror=incompatible-pointer-types]
  702 |         .write_end      = apfs_write_end,
      |                           ^~~~~~~~~~~~~~
/var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.c:702:27: note: (near initialization for ‘apfs_aops.write_end’)
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/lzfse/lzfse_decode_base.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/lzfse/lzfse_fse.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/lzfse/lzvn_decode_base.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/message.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/namei.o
  CC [M]  /var/lib/dkms/linux-apfs-rw/0.3.11/build/node.o
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.12.8-common/scripts/Makefile.build:234: /var/lib/dkms/linux-apfs-rw/0.3.11/build/inode.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/usr/src/linux-headers-6.12.8-common/Makefile:1962: /var/lib/dkms/linux-apfs-rw/0.3.11/build] Error 2
make: *** [/usr/src/linux-headers-6.12.8-common/Makefile:236: __sub-make] Error 2
make: Leaving directory '/usr/src/linux-headers-6.12.8-amd64'

Posted: **Tue Jan 07, 2025 12:09 pm**

There's a new version of apfs-dkms in Trixie. I've rebuilt it and uploaded it to the Test repo.
Let me know if it fixes the problem with the 6.12.8 kernel.

deb available here:
https://mxrepo.com/mx/testrepo/pool/tes ... 23_all.deb

Posted: **Tue Jan 07, 2025 1:47 pm**

The package installed without fuss on my daily so it must have been all that was needed. Will test again later today on my Macbook Air.

MX Linux Forum

Accessing APFS drives?

Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?

Re: Accessing APFS drives?