Diskmanagement.disenter error 49218

Please Apple - how is this still a massive problem for BigSur users? It is clearly a problem with the APFS driver implementation that has been fixed in later versions. Drives with this error mount perfectly well with all content visible on a Ventura Mac, they only fail on the Big Sur Mac - please fix this problem you caused by forcing the use of APFS for backups onto external disks.

Just upgraded to Sonoma.. and No ... the Time Machine disk is not mounting nor repairable from disk utility.. again.. I actually bought a new disk after my upgrade to osx 13 I think.. because of the same issue.. And as I read here it is not a new issue. It is a pity apple is not able to fix this problem. This bug/issue is a huge waist of time and money. How to get all my old backups back and have my disks run again? they just do not show up and/or mount/repair. I tried most of the suggestions mentioned here above. Perhaps I let a windows machine repair the disk.. hahahahaha .. and when that doesn't work erase.. when that works.. (?)

Same here on 13.5.2, but not only APFS, also MacOS Extended and ExFat (6 disks corrupted in the past year). All these disks where formatted with the MacOS disk utility. I suspect the bug is somewhere in the software dealing with the USB(-C) connections as only 1 of the instances involved me accidentally removing the disk before ejecting. Suggested solutions in previous posts for repairing the disks with Disk Utility or via command line in Terminal or via re-boot, all did not work.

Now only using APFS for Time Machine. Gradually moving all other disks (many) to ExFat. While MacOS is not able to repair the disk, I can fix the ExFat disk in a few minutes on Windows.

The MacOS Extended disk I could mount read-only and copy its data to a new disk, albeit very slow (5 days for 4.5 Tb). With ExFat was I able to mount the disk read-only on MacOS with WD software in two instances. In another instance I could not even mount it read only, but I can still access the disk on Windows ... The only disadvantage of ExFat is that is uses 20% more space (I found out when copying 4.5Tb from a %Tb OS Extended disk to a new 5Tb ExFAT disk, it was full at 4Tb from the original disk). Ever since my first APFS Time Machine disk became unusable a year ago (not broken, reformatted and still using it), I have two Time Machine back-up disks. And fortunately I started years ago to make 2 back-ups of all my data that does not reside on the computer or in the cloud. Apart from this being a lot of extra work, I even don't feel safe with double back-ups anymore when external drives are being destroyed on my MacBook (2020) so often. Had not used my simple Windows computer, that came for 10% of the price of my MacBook, for many years and now it's my data saving machine for broken ExFat drives ...

funny little trick,, if you have an iPad that can connect to your "dead" drive, you might be able to access all the data that way. it has always worked for me, just no way to eject it (apple???????) so I suggest turning of the iPad, then removing the drive. im using iPad Pro, but I guess any usb iPad should work.

After trying everything I found here, I re-formated the drive and it now comes up but I lost everything one the drive.

Just crashed another external USB with APFS, same error message. Unrepairable. APFS is a nightmare. Formatted the disc now with Mac OS Extended. Hope this helps in future cases.

i have the same problem with mac os x 14.2.1 . I've a 10TB WD external drive and using from terminal sudo /sbin/fsck_apfs -Fy /dev/disk4s1 i had the error

error: Device does not contain a valid APFS container. Container superblock is invalid. ** The container /dev/disk4s1 could not be verified completely.

For anyone else who's stuck with their APFS formatted drive unmountable after a power failure, there are a couple of options that worked for me that might work for you. The ones that didn't work for me but are solid first options were:

1. Using fsck (in my case fsck_apfs) in the Terminal, or the First Aid option in Disk Utility (they are basically the same thing according to the output). This gave me the error:

** Checking the container superblock.
   Checking the checkpoint with transaction ID 123038.
** Checking the space manager.
warning: (oid 0x6e98) cib: invalid o_cksum (0x0)
error: (oid 0x6e98) cib: found zeroed-out block
error: failed to read spaceman cib 1 at address 0x6e98
   Space manager is invalid.
** The container /dev/disk6 could not be verified completely.

1. Attaching the drive to my iPad. Nothing showed.

2. Attaching the drive to a Mac on Catalina or prior. I plugged the WD My Passport in an old Catalina laptop. It showed up in diskutil list with an error much the same as my newer Mac

3. Upgrade. I went from Monterey to Sonoma. The error messages were more opaque without the 49218 error code: "The disk <REDACTED> could not be unlocked. A problem was detected with the disk, which prevents it from being unlocked."

Two things did work for me:

1. Attaching to a PC and using Paragon's APFS for Windows driver free trial. I was able to see all the files and use the driver in read only mode. They really need to make an "APFS for Mac"—no joke!

   1. There was a "APFS Retrofit Kit" Sierra/El Capitan/Yosemite that is no longer available, but you might be able to track that down if you have a super old laptop.

2. Compiling fsapfstools from source and installing MacFuse as a kernel extension:

   1. Install MacFuse
   2. Shut down your Mac, power on, hold down the power button, and enable kernel extensions locally (remote is not needed) using these instructions: https://support.apple.com/en-au/guide/mac-help/mchl768f7291/mac
   3. Follow these instructions: https://github.com/libyal/libfsapfs/wiki/Building
      1. n.b., I specifically needed to add the following to /usr/local/share/config.site so that the build process would respect the headers from the MacPorts OpenSSL before running ./configure.

         CPPFLAGS=-I/opt/local/include
         LDFLAGS=-L/opt/local/lib
         

   4. Ensure to run the make install step, so that the tools are in your path
   5. Use diskutil list to discover the disk that is the container, and the one that is the actual APFS volume
      1. In my case there was both a physical disk as the container, and a synthesized disk with the volume
   6. Start a sudo session by using something like sudo bash or sudo zsh depending on your shell of choice
   7. Use hdiutil unmount /dev/<CONTAINER DISK> to unmount the container disk from above
   8. Use hdiutil eject /dev/<CONTAINER DISK> to eject the container disk
   9. MacFuse needs a volume icon, so I copied the one from my main drive with cp /Volumes/<BOOT VOLUME>/.VolumeIcon.icns .. In my case, the 'boot volume' was Macintosh HD, but you can copy a valid .icns file from anywhere
   10. Do mkdir mountpoint
   11. Do fsapfsmount -p <PASSWORD> -X volicon="<PATH TO VOLUME ICON>" -X allow_other /dev/<VOLUME DISK> mountpoint
       1. -p <PASSWORD>: add this if you have an encrypted volume. Put a space (" ") before the command so that it isn't recorded in your shell history!
       2. -X volicon="<PATH TO VOLUME ICON>": option so that MacFuse won't complain it doesn't have an icon for the volume
       3. -X allow_other: this will allow the MacFuse volume to be visible in Finder, but also to all non-root users
       4. /dev/<VOLUME DISK>: this is the volume disk that holds your actual partition, not the container
       5. mountpoint: this is the folder you made earlier and where all the files will be visible
   12. If everything went well, you can now copy your files to another volume, and marvel at how this open source software... just works 🤔
   13. After this is done, make sure you've exited the folder in terminal/finder, finished copying, etc. and use umount mountpoint to unmount the volume
   14. Finally, I would also uninstall MacFuse, return to the security settings and turn off those Kernel Extensions

This seems to be a failure common to APFS. SSDs (and HDDs) have capacitors that allow them enough time to flush the contents of their cache to disk on a hard power down. But it would seem there's some bugs in APFS that allow it's file database to enter an invalid state regardless. 3rd party APFS implementations seem to be robust to the little problems that MacOS baulk at, so if Apple can't write their file system defensively enough to avoid corruption, they ought to make it more resilient to corruption.

I've wasted a whole day on this, so I hope it helps someone.

(Mods: Sorry for the double post. I had no way to edit my post. Please delete the last one)