macOS 15 Sequoia had a hard time with CoreStorage – and thus encrypted HFS+ volumes – since it deprecated both technologies and callously crippled some important tools for working with them, but nonetheless it mostly still worked. While I’d often – but not always – have to manually unlock one of my HFS+ volumes – but not the others – at boot, and it also refused to convert some – but not all – volumes from HFS+ to APFS1, keeping me trapped in the situation – it ultimately still worked. I could get at my data and use the volumes more or less normally.
Unfortunately, in macOS 27 that’s no longer the case. Not only does Golden Gate just not support CoreStorage / encrypted HFS+ volumes, out of the box you can’t do anything with them – can’t mount them, can’t convert them to APFS, can’t even erase them. It renders your expensive storage hardware completely useless.
Worse, macOS 27 puts up a misleading dialog, upon boot, saying that macOS 28 (the next version) won’t support these volumes. I have no idea what Apple’s doing or thinking. Maybe it’s all just an embarrassing misunderstanding – the file system team told the notifications team that CoreStorage & encrypted HFS+ support is going away, and typoed the version number as 28 rather than 27?
Details
macOS 27 cannot mount CoreStorage volumes automatically or through any normal means. Worse, Disk Utility can’t mount them even when manually told to – it just fails with the cryptic error:
com.apple.DiskManagement.disenter error 49,153
diskutil mount also fails, this time with an error message that is a blatant lie:
disk27 is a CoreStorage Logical Volume which is locked; use "diskutil coreStorage unlockVolume"
$ diskutil cs unlockVolume BC304645-7D99-481E-931F-855B3011D89D
BC304645-7D99-481E-931F-855B3011D89D is already unlocked and is attached as disk27
$ diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
=========================================================
Name: Smash
Status: Online
Size: 2000054960128 B (2.0 TB)
Free Space: 0 B (0 B)
|
+-< Physical Volume 1B5A1754-184B-4F17-A797-BF69B4BB627F
| ----------------------------------------------------
| Index: 0
| Disk: disk10s2
| Status: Online
| Size: 2000054960128 B (2.0 TB)
|
+-> Logical Volume Family 376204CD-8048-4962-B05C-72F4FC16B77B
----------------------------------------------------------
Encryption Type: AES-XTS
Encryption Status: Unlocked
Conversion Status: Complete
High Level Queries: Fully Secure
| Passphrase Required
| Accepts New Users
| Has Visible Users
| Has Volume Key
|
+-> Logical Volume BC304645-7D99-481E-931F-855B3011D89D
---------------------------------------------------
Disk: disk27
Status: Online
Size (Total): 1999702634496 B (2.0 TB)
Revertible: No
LV Name: Smash
Volume Name: Smash
Content Hint: Apple_HFS
But what’s even worse about this dumpster fire is that macOS 27 can mount these volumes just fine – it’s just that all the normal ways to do it are completely broken. If you go down to a lower level and run mount_hfs directly, it does work:
$ sudo mkdir -p /Volumes/Smash
$ sudo mount_hfs -o rdonly /dev/disk27 /Volumes/Smash
$ ls /Volumes/Smash
Documents Pictures Scratch space
That said… that -o rdonly parameter… in principle it shouldn’t be required, but I could not get macOS 27 to let me mount any HFS-on-CoreStorage volume as read-write – no matter what I did, it always fails with error “Resource busy” (EBUSY). I spent a lot of time trying to debug this, and could find no evidence of anything having the volume in question open (nothing in lsof etc).
But wait, it gets worse.
macOS 27 can’t even erase the volume. All the normal tools – diskutil, Disk Utility, etc – fail with that same “Resource busy” error.
Workaround
Thankfully, with the help of Gemini 4 Argon, I did find a workaround. It’s convoluted, but takes only a few steps, thankfully.
First, while if you try to delete the logical volume group it ostensibly fails, it doesn’t completely fail – it does actually delete the logical volume(s) within:
$ diskutil cs delete 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
Started CoreStorage operation
Unmounting Logical Volumes
Destroying Logical Volume Group
Erasing disk10s2
newfs_hfs: cannot create filesystem on /dev/rdisk10s2: Resource busy
Mounting disk
Could not mount disk10s2 after erase
Error: -69832: File system formatter failed
1 💣 $ diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
=========================================================
Name: Smash
Status: Offline
Size: 2000054960128 B (2.0 TB)
Free Space: -none-
|
+-< Physical Volume 1B5A1754-184B-4F17-A797-BF69B4BB627F
----------------------------------------------------
(No properties)
$ diskutil cs delete 0DC0EFB1-23CC-45BC-B37D-C1BBEBDAFCEB
Started CoreStorage operation
Destroying Logical Volume Group
Error: -69783: Unable to delete the CoreStorage Logical Volume Group
You still can’t destroy it completely, nor can you erase the physical volume yet – the “Resource busy” errors persist. But, the trick is to restart – after that, you can then erase the volume.
So it seems that whatever broken thing is holding the physical volume (or logical volume group) in a ‘busy’ state is tied to the existence of the logical volume(s) therein, and once they’re deleted (and the machine rebooted) the bug stops being triggered.
Call for better workarounds
I’ve glossed over a lot of debugging and attempts I made to save the volume in-place, by either making it work as-is (even if only with e.g. hfsutils) or by converting it to APFS, but neither I nor Gemini 4 Argon could find anything that worked. It’s too late for me – I was forced to just delete all my HFS+ & CoreStorage volumes and rebuild them painstakingly from backups – but if anyone finds a way, I’d love to amend this post, for the benefit of future readers.