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: 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. Attaching the drive to my iPad. Nothing showed. 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 Upgrade. I went from Monterey to Sonoma. The error messages were more opaque without the 49218 error code: "The disk could not be unlocked. A problem was detected with the disk, which prevents it from being unlocked." Two things did work for me: 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! 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. Compiling fsapfstools from source and installing MacFuse as a kernel extension: Install MacFuse 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 Follow these instructions: https://github.com/libyal/libfsapfs/wiki/Building 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 Ensure to run the make install step, so that the tools are in your path Use diskutil list to discover the disk that is the container, and the one that is the actual APFS volume In my case there was both a physical disk as the container, and a synthesized disk with the volume Start a sudo session by using something like sudo bash or sudo zsh depending on your shell of choice Use hdiutil unmount /dev/<CONTAINER DISK> to unmount the container disk from above Use hdiutil eject /dev/<CONTAINER DISK> to eject the container disk 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 Do mkdir mountpoint Do fsapfsmount -p <PASSWORD> -X volicon="<PATH TO VOLUME ICON>" -X allow_other /dev/<VOLUME DISK> mountpoint -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! -X volicon="<PATH TO VOLUME ICON>": option so that MacFuse won't complain it doesn't have an icon for the volume -X allow_other: this will allow the MacFuse volume to be visible in Finder, but also to all non-root users /dev/<VOLUME DISK>: this is the volume disk that holds your actual partition, not the container mountpoint: this is the folder you made earlier and where all the files will be visible If everything went well, you can now copy your files to another volume, and marvel at how this open source software... just works 🤔 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 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)