libfsapfs_container_superblock_read_data: invalid object type: 0x30316369

[brbergami]

Hi there, first I'm thankful you take your time to check on this, I know these thread tend to be large and log-full.. This is my scenario: APFS volume, macOS Sonoma 14.1.1 (23B81). I tried with OSXFUSE (now macFUSE 4.5.0, went on an update since I tried couple months ago). Pulled 20231122 release. Recompiled with these flags, for openssl:

CC="xcrun gcc" ./configure
export PATH="/opt/homebrew/opt/openssl@3/bin:$PATH"
export CPPFLAGS="-I/opt/homebrew/opt/openssl@3/include $CPPFLAGS"
export LDFLAGS="-L/opt/homebrew/opt/openssl@3/lib $LDFLAGS"

Re-linked openssl just to be sure. make..

Testing fsapfsinfo with the password made me happy: files were there.

Funny enough, when tried fsapfsmount, it fails:

fsapfstools/mountpoint
fsapfsmount 20231122

Unable to open source volume
libfsapfs_container_superblock_read_data: invalid object type: 0x30316369.
libfsapfs_container_superblock_read_file_io_handle: unable to read container superblock data.
libfsapfs_internal_container_open_read: unable to read container superblock at offset: 0 (0x00000000).
libfsapfs_container_open_file_io_handle: unable to read from file IO handle.
mount_handle_open: unable to open container.

Tried just because I was with the doubt, but if I try with an incorrect password, throws the same error (which I know its the correct password, otherwise fsapfsinfo won't show anything). Just to clarify, my password requires the use of simple quotes (-p 'password') since it contains characters that confuses bash otherwise. Mount point exists in the same path as the binaries, and I'm using -X volicon= /Library/Filesystems/macfuse.fs/Contents/Resources/Volume.icns (path is valid), otherwise the execution borks and I have to kill the process. Executed as sudo, btw.

Let me know if there's any info I could dump in here to help understand this issue.

Cheers,

[joachimmetz]

libfsapfs_container_superblock_read_data: invalid object type: 0x30316369. indicates that you superblock object type does not make sense, eyeballing it translates to 01ci.

This might be related to unsupported format features or corrupted data have a look at https://github.com/libyal/libfsapfs/wiki/Troubleshooting#verbose-and-debug-output

[brbergami]

It's probably corrupted as the device stopped being mounted after a macOS crash. But what I don't get in this is why fsapfsinfo is able to see the folder/files inside of it...

I'll check the debug compiled version. I'm not quite sure I can run gdb on macOS.

[joachimmetz]

I'll check the debug compiled version. I'm not quite sure I can run gdb on macOS.

Debug output is not the same as running a debugger or debug symbols, these are all separate concepts.

But what I don't get in this is why fsapfsinfo is able to see the folder/files inside of it...

fsapfsmount might try to access more data such as content or extended attributes that fsapfsinfo is not

[joachimmetz]

No update from original reporter, closing issue.