Description of problem: apfs-fuse from fedora 34 package can't mount encrypted apfs filesystem. Version-Release number of selected component (if applicable): apfs-fuse-0-15.20200928git290028b.fc34.x86_64 How reproducible: Always Steps to Reproduce: 1. create an encrypted apfs filesystem (from macOS 11) 2. try to mount it with apfs-fuse Actual results: The following error occurs: $ sudo apfs-fuse /dev/sdd2 /mnt -d 31 Device /dev/sdd2 opened. Size is 16000000000 Mounting xid different from NXSB at 0 (xid = 36). xid = 36 Mounting xid 36 omap: oid=1027 xid=36 flags=0 size=0 paddr=1027 omap: oid=1028 xid=36 flags=0 size=0 paddr=1028 starting LoadKeybag @ 20003 Initialization of KeyManager failed. Unable to load container. Expected results: apfs-fuse asks for a password and successfully mount the filesystem after provided with the correct password. This was working with Fedora 33 package. And this is also working with apfs-fuse built from source downloaded from https://github.com/sgan81/apfs-fuse under Fedora 34, either the same commit as in the f34 package (290028b) or the latest (ee71aa5). $ sudo apfs-fuse /dev/sdd2 /mnt -d 31 Device /dev/sdd2 opened. Size is 16000000000 Mounting xid different from NXSB at 0 (xid = 36). xid = 36 Mounting xid 36 omap: oid=1027 xid=36 flags=0 size=0 paddr=1027 omap: oid=1028 xid=36 flags=0 size=0 paddr=1028 starting LoadKeybag @ 20003 all blocks verified Omap Lookup: oid=402 xid=24: oid=402 xid=24 => flags=0 size=1000 paddr=10000 Volume P1 is encrypted. starting LoadKeybag @ 20001 all blocks verified Enter Password: Additional info:
I can add that the same issue also occurs on plain unencrypted volumes now. Used to work fine in Fedora 33. $ sudo apfs-fuse -d 31 -v 4 /dev/sda2 -o allow_other /mnt/apfs4 Device /dev/sda2 opened. Size is 49865781248 Mounting xid different from NXSB at 0 (xid = 12905). xid = 12905 Mounting xid 12905 omap: oid=1026 xid=12905 flags=0 size=4294967295 paddr=1026 omap: oid=1029 xid=12905 flags=0 size=4294967295 paddr=1029 starting LoadKeybag @ 51f6b1 Initialization of KeyManager failed. Unable to load container.
Would be great if you could test the builds at https://koji.fedoraproject.org/koji/taskinfo?taskID=84504631
I tested the new build at https://koji.fedoraproject.org/koji/taskinfo?taskID=84504631 on Fedora 36. It's still the same. Encrypted filesystem doesn't mount, with the same error message as in the original report. Downloading latest from Github and manually building it continue to work.
It would be great if you could try and find what the differences are between the 2 builds, because what you tested *is* the latest from github. In particular, run ldd on the apfs-fuse binary, and check whether your version is linked against fuse2 or fuse3. If it's linked against fuse2, can you recompile against fuse3 (-DUSE_FUSE3=true), and test again? Hopefully it fails in the same way, and brings us closer to figuring this out.
Both are linked against fuse3. [user@localhost build]$ ldd ./apfs-fuse linux-vdso.so.1 (0x00007ffe5d5c8000) libfuse3.so.3 => /lib64/libfuse3.so.3 (0x00007fadb2e99000) libz.so.1 => /lib64/libz.so.1 (0x00007fadb2e7f000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fadb2e6c000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fadb2c38000) libm.so.6 => /lib64/libm.so.6 (0x00007fadb2b5a000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fadb2b3a000) libc.so.6 => /lib64/libc.so.6 (0x00007fadb2936000) /lib64/ld-linux-x86-64.so.2 (0x00007fadb2eeb000) [user@localhost build]$ ldd /usr/bin/apfs-fuse linux-vdso.so.1 (0x00007ffcd9fb4000) libfuse3.so.3 => /lib64/libfuse3.so.3 (0x00007ff9ab577000) libz.so.1 => /lib64/libz.so.1 (0x00007ff9ab55d000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007ff9ab54a000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff9ab316000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff9ab2f6000) libc.so.6 => /lib64/libc.so.6 (0x00007ff9ab0f4000) libm.so.6 => /lib64/libm.so.6 (0x00007ff9ab014000) /lib64/ld-linux-x86-64.so.2 (0x00007ff9ab61f000)
Ok, I tried to build the rpm without LTO. Now it works. https://fedoraproject.org/wiki/LTOByDefault
Filed upstream as https://github.com/sgan81/apfs-fuse/issues/164
Could you please check whether the builds at https://koji.fedoraproject.org/koji/taskinfo?taskID=85245468 work for you? If they do, I'll spin an update, thanks.
Yes, the new build apfs-fuse-0-19.20200928gitee71aa5.fc37 works.
FEDORA-2022-d238cbf409 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d238cbf409
FEDORA-2022-0e08664d2d has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-0e08664d2d
FEDORA-2022-0e08664d2d has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-0e08664d2d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0e08664d2d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-d238cbf409 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-d238cbf409` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d238cbf409 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-d238cbf409 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-0e08664d2d has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FYI I am running FEDORA-2022-0e08664d2d in fedora 36... It still has this problem. Perhaps there is some other subtle library difference that is causing this?? I also have the same problem in Ubuntu 22. I was trying to mount a filevault-protected drive that is having trouble in Catalina.