issues reading Linux hfs mount from mounted single extent logical volume
gyrex opened this issue · 23 comments
Hi guys,
I'm having some issues trying to mount my external disk to Ubuntu and I've spent a day on this but really need some help if possible please? Initially, I had issues because I figured out my kernel wasn't built with hfsplus support so I had to recompile and now I can see hfsplus listed in /proc/filesystems.
This disk was created in Mac Mojave. I'm running fvdemount version 20190104
Here is my workflow:
sudo fvdemount -p <password> /dev/sda2 /mnt/Ext4TB_raw/
Mounts OK, no errors printed to screen or dmesg.
sudo mount -o loop,ro /mnt/Ext4TB_raw/fvde1 /mnt/Ext4TB
Returns:
mount: /mnt/Ext4TB: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
From dmesg after attempting to mount decrypted volume:
[Mon Feb 25 09:52:27 2019] print_req_error: I/O error, dev loop0, sector 7812644736
[Mon Feb 25 09:52:27 2019] print_req_error: I/O error, dev loop0, sector 7812644736
[Mon Feb 25 09:52:27 2019] Buffer I/O error on dev loop0, logical block 976580592, async page read
[Mon Feb 25 09:52:27 2019] print_req_error: I/O error, dev loop0, sector 7812644736
[Mon Feb 25 09:52:27 2019] Buffer I/O error on dev loop0, logical block 976580592, async page read
[Mon Feb 25 09:52:27 2019] print_req_error: I/O error, dev loop0, sector 7812644862
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x4002b48)
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x4002b48)
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[Mon Feb 25 09:52:27 2019] F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
Interestingly, when I try and run fvdemount with verbose logging enabled (-v), it won't decrypt the disk as it does without logging - it seems to stop during the decryption process. I built fvdemount from sources with logging enabled.
This project is experimental can you send me debug output to see if the issue can be fixed. Also see: https://github.com/libyal/libfvde/wiki/Troubleshooting#format-or-behavioral-errors
Hi Joachim,
Thanks for your response. I've attached the output from:
sudo fvdemount -v -p <password> /dev/sda2 /mnt/Ext4TB_raw
It seems to stall/hang at the end so I had to kill the process, I'm not sure if this is normal behaviour from a verbose output? When I run it without verbose output, the command completes without error and exits normally.
Hi @joachimmetz,
I hope you're well. I was wondering if you've had a chance to review the log I sent? Is there anything else I can send you to help?
@gyrex thanks for the log
The "stall" is normal this is the program remaining to run in the foreground with the -v option. A quick glance at the logs shows that the format of the image is not fully supported and will require more research into the format.
@joachimmetz If there's anything else I can do to help you diagnose this, don't hesitate to let me know mate.
@gyrex sry have been busy traveling and other obligations, I'll try to have a look as soon as time permits.
Same issue here. Just leaving the comment to receive notifications for updates on this issue :-) 👍
I have the same issue trying to access an encrypted time machine volume created under Mac OS 10.14. AFAIK the used file system is APFS.
I also tried to inspect the fvde1 device file with fsapfsinfo and got the following errors:
$ sudo fsapfsinfo /mnt/usb/fvde1
fsapfsinfo 20190210
Unable to open: /mnt/usb/fvde1.
libfsapfs_container_superblock_read_data: invalid object type: 0x00000000.
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.
info_handle_open_input: unable to open input container.
fvdeinfo -p /dev/sdf2 gives the following output:
fvdeinfo 20190104
Core Storage information:
Physical volume:
Size: 2000054960128 bytes
Encryption method: AES XTS
Logical volume:
Size: 1999693152256 bytes
I have the same issue trying to access an encrypted time machine volume created under Mac OS 10.14. AFAIK the used file system is APFS.
So APFS does not use FVDE (CoreStorage with FileVault) it has built-in encryption instead.
Your file system is likely HFS+.
I also tried hfsplus:
sudo mount -t hfsplus -o ro /mnt/usb/fvde1 /mnt/source
mount: /mnt/source: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/loop15 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.
@thawn per an earlier comment "This project is experimental can you send me debug output to see if the issue can be fixed".
Can you also send a hexadecimal representation of the unencrypted volume header to make sure your file system is really HFS+.
I finally managed to mount my time machine using --force and this FUSE driver https://github.com/0x09/hfsfuse
For future reference, this is what I did under Ubuntu 20.04 (maybe this would be useful information for the Mounting wiki page):
sudo apt install libfvde-utils libfuse-dev
git clone https://github.com/0x09/hfsfuse
cd hfsfuse
make config
make
sudo make install
sudo fvdeinfo -p <password> /dev/sdf2 /mnt/usb/
sudo hfsfuse --force /mnt/usb/fvde1 /mnt/timemachine/I have not tried to write to the disk because I don't need write access and am afraid to break something.
I have not tried to write to the disk because I don't need write access and am afraid to break something.
This project provides no write support at the moment.
It could be that the hfsfuse implementation is more error tolerant than the hfsplus implementation.
Can you send me debug output anyway to address the issue?
@joachimmetz I just compiled libfvde from source and enabled debugging and verbose output (before I used the libfvde-utils package provided by ubuntu 20.04 that does not come with debugging support).
However, when I run fvdemount -v -p <password> <source> <target>, I only get this output:
fvdemount 20200817
libcfile_internal_file_get_size: device media size: 2000054960128
This is what I did to build and install:
sudo apt install git autoconf automake autopoint libtool pkg-config flex bison
git clone https://github.com/libyal/libfvde.git
cd libfvde
./synclibs.sh
./autogen.sh
./configure --enable-verbose-output --enable-debug-output
make
sudo make install
I also made sure to uninstall libfvde-utils and that which fvdemount returns /usr/local/fvdemount
First Ubuntu 20.04 seems to provide a version of libfvde that is not the latest release https://packages.ubuntu.com/focal/libfvde-utils
(before I used the libfvde-utils package provided by ubuntu 20.04 that does not come with debugging support).
There is no need to do so, debugging support is intended for format debugging. However this means that Ubuntu 20.04 is providing highly experimental code.
So there is no need to install the build with debug output:
After:
git clone https://github.com/libyal/libfvde.git
cd libfvde
./synclibs.sh
./autogen.sh
./configure --enable-verbose-output --enable-debug-output
make
Try:
./fvdetools/fvdeinfo -v -p <password> <source> 2> debug.log
that last command worked (although I do not understand why the file installed in /usr/local/bin did not work)
that last command worked
thx, having a more detailed look as soon as time permits to see what I can find
(although I do not understand why the file installed in /usr/local/bin did not work)
Some possibilities:
- the dynamic library cache still points to the version without verbose output
- removing the libfvde-utils package likely did not remove libfvde, so your newly built tools are talking to a library without debug output
having a more detailed look as soon as time permits to see what I can find
Great, thanks a lot for all your work! Being able to access my time machine backup really saved me here 😅
Based on fvdemount.txt, looks like a single extent image
libfvde_encrypted_metadata_read_type_0x0305: number of entries : 1
libfvde_encrypted_metadata_read_type_0x0305: unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 logical block number : 0
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 number of blocks : 976580608
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown3 : 0x00400000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown4 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown5 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 physical block number : 16384
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown6 : 0x00000000
976580608 * 4096 = 4000074170368
libfvde_volume_open_read: physical volume size : 4000443056128
libfvde_volume_open_read: logical volume offset : 0x04000000
libfvde_volume_open_read: logical volume size : 4000074170368
libfvde_io_handle_read_logical_volume_header: block size : 8192
libfvde_io_handle_read_logical_volume_header: number of blocks : 488290304
488290304 * 8192 = 4000074170368
And FS header is look correctly decrypted
libfvde_sector_data_read: sector data:
00000000: 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 1d 1c H+....!. HFSJ....
00000010: d8 4e f5 2d d8 98 43 94 00 00 00 00 d8 4e 5a 7d .N.-..C. .....NZ}
00000020: 00 00 ed 96 00 00 28 f4 00 00 20 00 1d 1a b8 00 ......(. .. .....
00000030: 03 3d 6a 26 15 7a a8 00 00 01 00 00 00 01 00 00 .=j&.z.. ........
00000040: 00 01 19 3b 01 9f 7a 5e 00 00 00 00 00 00 00 01 ...;..z^ ........
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00000060: 00 00 00 00 00 00 00 00 17 26 be dd fa d0 31 71 ........ .&....1q
00000070: 00 00 00 00 03 a3 60 00 03 a3 60 00 00 00 1d 1b ......`. ..`.....
Based on debug.log also single extent
libfvde_encrypted_metadata_read_type_0x0305: number of entries : 1
libfvde_encrypted_metadata_read_type_0x0305: unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown1 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 logical block number : 0
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 number of blocks : 488206336
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown3 : 0x00400000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown4 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown5 : 0x00000000
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 physical block number : 16384
libfvde_encrypted_metadata_read_type_0x0305: entry: 000 unknown6 : 0x00000000
Unable to reproduce with test images created with https://github.com/dfirlabs/core-storage-specimens. Using https://github.com/libyal/libfshfs with debug output might indicate what is wrong
Unable to reproduce, I opt to give libfvde-experimental-20220120 a try. Closing this issue for now, reopen if issue persist.