Page 2 of 2

Re: Accessing APFS drives?

Posted: Wed Oct 30, 2024 11:05 pm
by timkb4cq
There is a much newer (April 2024) version in github. I'll try packaging that tomorrow.

Re: Accessing APFS drives?

Posted: Thu Oct 31, 2024 1:39 am
by m_pav
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

Re: Accessing APFS drives?

Posted: Fri Nov 01, 2024 6:23 pm
by timkb4cq
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

Re: Accessing APFS drives?

Posted: Sat Nov 02, 2024 12:46 am
by m_pav
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.
Image

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

Re: Accessing APFS drives?

Posted: Sat Nov 02, 2024 12:23 pm
by pax-eterna
Thanks, will do that.

Re: Accessing APFS drives?

Posted: Sun Nov 03, 2024 4:30 am
by m_pav
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.

Re: Accessing APFS drives?

Posted: Mon Jan 06, 2025 11:29 pm
by m_pav
@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'

Re: Accessing APFS drives?

Posted: Tue Jan 07, 2025 12:09 pm
by timkb4cq
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

Re: Accessing APFS drives?

Posted: Tue Jan 07, 2025 1:47 pm
by m_pav
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.