2

I'm trying to mount an old external SSD with an encrypted APFS volume on it.

Disk Utility shows it as Not Mounted and attempting to mount it results in the following:

Could not mount “disk2s2”. (com.apple.DiskManagement.disenter error -119930868.)

Disk Utility First Aid on the disk shows ‘The partition map appears to be OK’ and no issues reported. First Aid on the volume isn't possible, as the option is greyed out.

fsck_apfs is also not happy, returning

error: Device does not contain a valid APFS container.
Container superblock is invalid.

Here's the output of diskutil list and fsck_apfs.

$ diskutil list disk2 /dev/disk2 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.1 GB disk2 1: EFI EFI 209.7 MB disk2s1 2: Apple_APFS 499.9 GB disk2s2 $ sudo fsck_apfs /dev/disk2 0000: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 01b0: 0000 0000 0000 0000 0000 0000 0000 00fe |................| 01c0: ffff eefe ffff 0100 0000 ff5f 383a 0000 |............8...| 01d0: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 01f0: 0000 0000 0000 0000 0000 0000 0000 55aa |..............U.| 0200: 4546 4920 5041 5254 0000 0100 5c00 0000 |EFI.PART........| 0210: 96f5 54be 0000 0000 0100 0000 0000 0000 |..T.............| 0220: ff5f 383a 0000 0000 2200 0000 0000 0000 |..8.............| 0230: de5f 383a 0000 0000 a8b0 39fd 4b4b c648 |..8.......9.KK.H| 0240: b814 49a3 9175 b71a 0200 0000 0000 0000 |..I..u..........| 0250: 8000 0000 8000 0000 f696 6c12 0000 0000 |..........l.....| 0260: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 0400: 2873 2ac1 1ff8 d211 ba4b 00a0 c93e c93b |.s.......K......| 0410: 92e8 8efc df20 0442 94ac ad19 1e9e 54ef |.......B......T.| 0420: 2800 0000 0000 0000 2740 0600 0000 0000 |................| 0430: 0000 0000 0000 0000 4500 4600 4900 2000 |........E.F.I...| 0440: 5300 7900 7300 7400 6500 6d00 2000 5000 |S.y.s.t.e.m...P.| 0450: 6100 7200 7400 6900 7400 6900 6f00 6e00 |a.r.t.i.t.i.o.n.| 0460: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 0480: ef57 347c 0000 aa11 aa11 0030 6543 ecac |.W4........0eC..| 0490: 6694 dc64 e4e5 2f4b b022 8513 5bb1 06e9 |f..d...K........| 04a0: 2840 0600 0000 0000 d75f 383a 0000 0000 |..........8.....| 04b0: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 0ff0: 0000 0000 0000 0000 0000 0000 0000 0000 |................| error: Device does not contain a valid APFS container. Container superblock is invalid. ** The container /dev/disk2 could not be verified completely. $ sudo fsck_apfs /dev/disk2s2 0000: eb58 9042 5344 2020 342e 3400 0240 2000 |.X.BSD..4.4.....| 0010: 0200 0000 00f8 0000 2000 ff00 2840 0600 |................| 0020: b01f 323a 74d1 0100 0000 0000 0200 0000 |..2.t...........| 0030: 0100 0600 0000 0000 0000 0000 0000 0000 |................| 0040: 8000 29fa 1773 6f55 4e54 4954 4c45 4420 |.....soUNTITLED.| 0050: 2020 4641 5433 3220 2020 fa31 c08e d0bc |..FAT32....1....| 0060: 007c fb8e d8e8 0000 5e83 c619 bb07 00fc |................| 0070: ac84 c074 06b4 0ecd 10eb f530 e4cd 16cd |...t.......0....| 0080: 190d 0a4e 6f6e 2d73 7973 7465 6d20 6469 |...Non.system.di| 0090: 736b 0d0a 5072 6573 7320 616e 7920 6b65 |sk..Press.any.ke| 00a0: 7920 746f 2072 6562 6f6f 740d 0a00 0000 |y.to.reboot.....| 00b0: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 01f0: 0000 0000 0000 0000 0000 0000 0000 55aa |..............U.| 0200: 5252 6141 0000 0000 0000 0000 0000 0000 |RRaA............| 0210: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 03e0: 0000 0000 7272 4161 f1b9 e800 0300 0000 |....rrAa........| 03f0: 0000 0000 0000 0000 0000 0000 0000 55aa |..............U.| 0400: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 0c00: eb58 9042 5344 2020 342e 3400 0240 2000 |.X.BSD..4.4.....| 0c10: 0200 0000 00f8 0000 2000 ff00 2840 0600 |................| 0c20: b01f 323a 74d1 0100 0000 0000 0200 0000 |..2.t...........| 0c30: 0100 0600 0000 0000 0000 0000 0000 0000 |................| 0c40: 8000 29fa 1773 6f55 4e54 4954 4c45 4420 |.....soUNTITLED.| 0c50: 2020 4641 5433 3220 2020 fa31 c08e d0bc |..FAT32....1....| 0c60: 007c fb8e d8e8 0000 5e83 c619 bb07 00fc |................| 0c70: ac84 c074 06b4 0ecd 10eb f530 e4cd 16cd |...t.......0....| 0c80: 190d 0a4e 6f6e 2d73 7973 7465 6d20 6469 |...Non.system.di| 0c90: 736b 0d0a 5072 6573 7320 616e 7920 6b65 |sk..Press.any.ke| 0ca0: 7920 746f 2072 6562 6f6f 740d 0a00 0000 |y.to.reboot.....| 0cb0: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 0df0: 0000 0000 0000 0000 0000 0000 0000 55aa |..............U.| 0e00: 5252 6141 0000 0000 0000 0000 0000 0000 |RRaA............| 0e10: 0000 0000 0000 0000 0000 0000 0000 0000 |................| . . . 0fe0: 0000 0000 7272 4161 f1b9 e800 0300 0000 |....rrAa........| 0ff0: 0000 0000 0000 0000 0000 0000 0000 55aa |..............U.| error: Device does not contain a valid APFS container. Container superblock is invalid. ** The container /dev/disk2s2 could not be verified completely. $ sudo fsck_msdos -n /dev/rdisk2s2 ** /dev/rdisk2s2 ** Phase 1 - Preparing FAT ** Phase 2 - Checking Directories ** Phase 3 - Checking for Orphan Clusters 0 files, 488062496 KiB free (15251953 clusters)

I also tried drat by the author of How to recover apparently missing directory and data from APFS volume? `found zeroed-out block` which fails to recover because of a lack of support for encryption (#71).

$ sudo ./drat inspect /dev/disk12s2 Opening file at `/dev/disk12s2` in read-only mode ... OK. Simulating a mount of the APFS container. Reading container superblock at address 0x0, assuming default block size of 4096 bytes ... Actual block size stated in container superblock is 119156 bytes; re-reading block 0x0 using new block size ... validating checksum ... FAILED. !! APFS ERROR !! Checksum of block 0x0 should validate, but it doesn't. Proceeding as if it does. Details of block 0x0: -------------------------------------------------------------------------------- Stored checksum: 0x20204453429058eb OID: 0x20400200342e34 XID: 0xf80000000002 Storage type: Virtual Type flags: (no flags) Type: Reserved type/subtype (0x20) Subtype: Unknown value (0x4028) Keybag location: none (spans 0 blocks) Media keybag location: none (spans 0 blocks) Magic string: ?2: Latest version of Apple APFS software that mounted this container: 0.0.0.0.0 Block size: 119156 bytes Block count: 8589934592 (last block 0x1ffffffff) Supported features: - The volumes in this container support defragmentation. Supported read-only compatible features: - No flags. Backward-incompatible features: - No flags. UUID: 4E544954-4C45-4420-2020-464154333220 Next OID: 0xbcd08ec031fa2020 Next XID: 0xe8d88efb7c00 Space manager Ephemeral OID: 0x656b20796e612073 Object map Physical OID: 0x626572206f742079 Reaper Ephemeral OID: 0xa0d746f6f Other flags: - No flags. -------------------------------------------------------------------------------- !! APFS ERROR !! Block 0x0 should be a container superblock, but it isn't. Proceeding as if it is. !! APFS ERROR !! Container superblock at 0x0 doesn't have the correct magic number. Proceeding as if it does. Locating the checkpoint descriptor area: - Its length is 432440158 blocks. - It is contiguous. - The address of its first block is 0xcd0eb40674c084ac. Loading the checkpoint descriptor area into memory ... FAILED: read_blocks: The specified starting block address, 0xcd0eb40674c084ac, is invalid, as it lies outside of the file `/dev/disk12s2`. ABORT: Failed to read all blocks in the checkpoint descriptor area.

gpt recover fails with "operation not permitted" per gpt operation not permitted in Ventura. Disk Drill finds no missing partitions, so tries to deep scan for files which fails due to encryption.

gdisk seems happy with the state of both the main and backup GPT headers:

Recovery/transformation command (? for help): ? b use backup GPT header (rebuilding main) c load backup partition table from disk (rebuilding main) d use main GPT header (rebuilding backup) e load main partition table from disk (rebuilding backup) f load MBR and build fresh GPT from it g convert GPT into MBR and exit h make hybrid MBR i show detailed information on a partition l load partition data from a backup file m return to main menu o print protective MBR data p print the partition table q quit without saving changes t transform BSD disklabel partition v verify disk w write table to disk and exit x extra functionality (experts only) ? print this menu Recovery/transformation command (? for help): p Disk /dev/disk7: 976773120 sectors, 465.8 GiB Sector size (logical): 512 bytes Disk identifier (GUID): FD39B0A8-4B4B-48C6-B814-49A39175B71A Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 976773086 Partitions will be aligned on 8-sector boundaries Total free space is 13 sectors (6.5 KiB) Number Start (sector) End (sector) Size Code Name 1 40 409639 200.0 MiB EF00 EFI System Partition 2 409640 976773079 465.6 GiB AF0A Recovery/transformation command (? for help): i Partition number (1-2): 2 Partition GUID code: 7C3457EF-0000-11AA-AA11-00306543ECAC (Apple APFS) Partition unique GUID: 64DC9466-E5E4-4B2F-B022-85135BB106E9 First sector: 409640 (at 200.0 MiB) Last sector: 976773079 (at 465.8 GiB) Partition size: 976363440 sectors (465.6 GiB) Attribute flags: 0000000000000000 Partition name: '' Recovery/transformation command (? for help): v No problems found. 13 free sectors (6.5 KiB) available in 2 segments, the largest of which is 7 (3.5 KiB) in size. Recovery/transformation command (? for help): b Recovery/transformation command (? for help): p Disk /dev/disk7: 976773120 sectors, 465.8 GiB Sector size (logical): 512 bytes Disk identifier (GUID): FD39B0A8-4B4B-48C6-B814-49A39175B71A Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 976773086 Partitions will be aligned on 8-sector boundaries Total free space is 13 sectors (6.5 KiB) Number Start (sector) End (sector) Size Code Name 1 40 409639 200.0 MiB EF00 EFI System Partition 2 409640 976773079 465.6 GiB AF0A Recovery/transformation command (? for help): i Partition number (1-2): 2 Partition GUID code: 7C3457EF-0000-11AA-AA11-00306543ECAC (Apple APFS) Partition unique GUID: 64DC9466-E5E4-4B2F-B022-85135BB106E9 First sector: 409640 (at 200.0 MiB) Last sector: 976773079 (at 465.8 GiB) Partition size: 976363440 sectors (465.6 GiB) Attribute flags: 0000000000000000 Partition name: ''

What are my next steps?

Improve this question
6
  • Did you ever resolve this? Commented Sep 27 at 1:30
  • @LincDavis Unfortunately not, if you have any ideas I would appreciate anything to try! Commented Sep 27 at 11:35
  • Try fsck_apfs /dev/disk2s2. The device number may be different. Commented Sep 27 at 14:30
  • Thanks @LincDavis, both disk2 and disk2s2 were tried in the first code block where you can find the corresponding output Commented Sep 27 at 18:02
  • OK, I missed that. It sure looks like the nominal APFS container is actually a FAT32 volume. How it got that way I can't imagine. You would have to use a tool such as gpt(8) to recover the partition table on the drive. I have no experience in this area because I always have backups, so I'm reluctant to make a suggestion that could cause irrecoverable data loss, but maybe something like gpt recover ...? Commented Sep 27 at 18:22

1 Answer 1

Reset to default
0

All I know about gpt is what's in the man page. I know nothing at all about any third-party utilities.

Going by the man page, there should already be a backup partition table on the drive. The following command should replace the existing, apparently corrupt, table with that backup (which may also be corrupt):

gpt recover /dev/disk2

Here you may have to change the device number from 2 to whatever it is now. Make sure you check with diskutil so you don't operate on the wrong device. If you get a permission error, preface the command with sudo.

If the problem isn't solved--and I'm not very hopeful that it will be-- then you'll need to delve into the lore of partition surgery. I consider this to be the domain of data-recovery specialists. There used to be a guy @klanomath on this site who seemed to know this stuff very well, but he hasn't been active for several years. An example of his advice is in the question How to fix broken GPT, GUID and unmountable, no type volumes?. I'd start there.

Improve this answer
2
  • Thanks, I've had trouble with gpt recover (edited question with info) and doing what seems to be the equivalent operation "b use backup GPT header (rebuilding main)" in gdisk doesn't seem to change anything. I've added gdisk output above, thank you Commented Sep 28 at 15:10
  • According to the gdisk output, Partition 2 has type 7C3457EF-0000-11AA-AA11-00306543ECAC for an APFS container. But according to the fsck_apfs output, it actually has a FAT32 header. Assuming that the header is correct, then the next thing I would try is to block-copy the device file of that partition to another volume that is already formatted as FAT32, using dd. I think you already know how to do that. Make sure the volumes are the same size. You should use another external drive as the destination. A USB flash drive would do. Commented Sep 28 at 21:15

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.