macOS 27 CoreStorage Support: 🔥 Encrypted HFS+ Fixes
MacOS 27 CoreStorage support is breaking encrypted HFS+—see why CoreStorage won’t mount, how read-only fixes work, and safer erase/convert steps.
macOS 27 and CoreStorage: What Breaks, and What You Can Do
A macOS upgrade is not supposed to leave an attached data drive inaccessible. Yet a report on testing macOS 27 - also called Golden Gate - describes exactly that for CoreStorage volumes, including encrypted HFS+ volumes. The drive may look unlocked, but Finder, Disk Utility, and standard diskutil commands can't mount it normally. Attempts to convert or erase it can fail too.
That distinction matters. A drive that simply isn't showing up in Finder might just need a password or a mount command. A drive whose storage stack is in a broken state is different: there may still be a way to read the data through a lower-level workaround, while normal repair and migration tools refuse to touch it. The report also includes a startup warning that names macOS 28, even though the failures show up in macOS 27.
This article walks through the storage layers involved, the reported symptoms, a read-only mounting method, and a cautious sequence for reclaiming a drive if preserving the contents is no longer the goal. The commands here aren't a replacement for a backup or Apple's support guidance - and some of them can destroy data.
What does macOS 27 break with CoreStorage volumes?
The reported failure isn't just "an old file system is deprecated." It's that the usual macOS workflows for accessing and managing a CoreStorage-backed HFS+ volume stop working - even when the volume is shown as online and unlocked.
CoreStorage and HFS+ are related, but they aren't the same layer. CoreStorage manages the underlying storage and can handle encryption and logical-volume behavior. HFS+ is the file system that actually holds folders and files. In the reported setup, an encrypted HFS+ volume sits on top of a CoreStorage logical volume. If macOS mishandles that combination, mounting, conversion, and erasure can all be affected - not just file browsing.
The difference between deprecated and unusable
The earlier macOS 15 Sequoia experience described in the report was unreliable but not fully blocking. The user sometimes had to unlock a volume manually at startup, and some attempts to convert HFS+ volumes to APFS failed. Even then, the volumes were still usable once they were accessible.
The macOS 27 behavior is more severe. The report says the system can't mount the volumes through normal means, can't convert them successfully, and may refuse to erase them. In one diagnostic listing, CoreStorage shows the logical volume as online and the encryption status as unlocked. That's a big clue: this doesn't look like a "forgot the password" problem or an offline physical disk problem.
It also doesn't prove every Mac, every CoreStorage setup, or every HFS+ disk is affected. The report describes what happened during a specific testing experience. Treat it as a compatibility warning, not blanket proof that all legacy volumes will fail in the same way.
The startup warning adds confusion
The system reportedly shows a boot-time dialog warning that macOS 28 will not support these volumes. But the access failures are already happening in macOS 27. That mismatch makes the dialog a weak guide for what you should do right now. It could be a message error, or it could reflect a difference between the warning wording and the actual behavior. The report can't confirm Apple's intent.
Practical takeaway: If you rely on a CoreStorage or encrypted HFS+ data volume, don't assume a version-number warning buys you time. Make sure you have a separate, restorable copy of the data before upgrading or attempting any repair.
Why do Disk Utility and diskutil fail?
Disk Utility is usually the first stop when a disk won't mount. In the report, trying to mount the volume through Disk Utility fails with com.apple.DiskManagement.disenter error 49,153. The GUI doesn't say whether the issue is encryption, the file system, the logical volume, or a device state problem.
The command-line tools are more talkative, but the messages don't line up neatly with what the system claims. A normal mount attempt says the CoreStorage logical volume is locked and suggests unlocking it. The suggested unlock command then says the volume is already unlocked and attached as a disk. A CoreStorage listing also shows encryption status as unlocked and the logical volume as online.
An error message is not always a diagnosis
That's worth keeping in mind: a command can spit out a reasonable-sounding instruction while its premise is wrong. Repeating the unlock operation won't help if the volume is already unlocked - the real problem is somewhere else in the normal mount path.
The report also describes a failed attempt to convert the volume to APFS with diskutil apfs convert. The command starts by identifying the target as an encrypted HFS+ data volume backed by CoreStorage, then fails during the HFS-to-APFS conversion. It exits with error -69860 and restores the original type. In other words, that conversion attempt didn't give a reliable way out of the broken mount behavior.
Erasing runs into trouble too. Attempts to erase through Disk Utility or diskutil hit Resource busy errors. That's especially confusing when nothing obvious seems to be using the disk. The report says the user checked for open processes, but the error remained.
What this means before you troubleshoot
Don't treat any single message as proof the data is gone - or proof it's safe to erase. The reported volume may still be readable through a lower-level mount command even though normal mount and conversion paths fail. On the flip side, "unlocked" or visible status doesn't guarantee macOS can safely write to the volume.
A sensible order of operations looks like this:
- Identify the physical disk and the logical volume precisely.
- Check whether the volume is locked, online, or already attached before repeating unlock commands.
- Avoid repeated conversion or erase attempts if the data matters and you don't have a verified backup.
- Prefer read-only access for recovery work until you understand what state the volume is actually in.
These steps won't "repair macOS 27," but they can prevent you from making a difficult recovery harder by writing to a storage state you haven't confirmed.
Can you still read an affected HFS+ volume?
In the reported tests, yes - but only through a lower-level route, and only for read-only access. Disk Utility and normal diskutil mount attempts failed, but calling mount_hfs directly was able to attach the HFS+ file system and expose the files.
The example sequence was:
sudo mkdir -p /Volumes/Smash
sudo mount_hfs -o rdonly /dev/disk27 /Volumes/Smash
ls /Volumes/Smash
Here, /dev/disk27 and /Volumes/Smash are specific to the example. Don't copy the device identifier blindly. On your Mac, the disk identifier may differ, and mounting the wrong device is a real risk. Confirm the correct logical volume first using tools on your system.
Why read-only is the right boundary
The -o rdonly option is the key detail. The report says read-write mounting failed with Resource busy, even after attempts to identify a process holding the volume open. Read-only worked, but it didn't provide a reliable path to write.
So think of this as a data-recovery or data-copy workaround, not a fix. If you can access the files, copy the important data to a separate healthy disk. Don't assume that a successful directory listing means the volume is stable enough for regular use, and don't use the source volume as the destination for a backup.
Read-only mounting also reduces the chance of accidental changes while you figure out what's going on. It still can't guarantee every file is recoverable, and it doesn't remove the underlying CoreStorage/HFS+ compatibility issue. If the data is irreplaceable - especially if the disk shows other signs of failure - consider professional recovery help before running anything that modifies the storage structure.
A safe sequence for accessing files
If you're comfortable in Terminal, keep the goal narrow: identify the volume, mount it read-only, copy the data elsewhere, then verify the copied files open. Don't move, rename, or delete files on the affected volume during the first pass.
A useful checklist is:
- Confirm the device identifier instead of assuming it matches the example.
- Create a mount point that doesn't already contain important data.
- Use the read-only option shown above.
- Copy to a different physical disk with enough free space.
- Check a representative sample of files from the copy before you call it done.
If the read-only mount fails on your machine, stop rather than trying more "creative" destructive commands. This workaround is specific to the reported case, not a universal recovery method.
How can you erase or replace a broken volume?
The reported workaround is only relevant if your goal is to abandon the existing CoreStorage volume and reuse the physical storage. It's not a method for saving the files. The sequence can destroy the logical volume and its contents, so don't run it unless you have a verified backup - or you've already decided the data is expendable.
In the report, the first attempt to delete the CoreStorage logical volume group didn't finish cleanly. The command said it was destroying the group and erasing the physical volume, then failed because newfs_hfs couldn't create a file system - the device was Resource busy. It also couldn't mount the disk after the erase attempt.
Even though the erase didn't complete, the attempt still changed state: the logical volume was removed, while the logical volume group remained listed as offline. A second delete attempt then failed with an error saying the group couldn't be deleted. The user restarted the Mac at that point. After the restart, they were able to erase the physical volume.
Why the restart appeared to help
One explanation suggested by the report is that some system state kept the physical volume (or the logical volume group) marked busy while the logical volume still existed. After the logical volume was deleted and the Mac restarted, that condition no longer blocked erasure.
That's an observation from the reported case, not a confirmed explanation from Apple. Treat the restart behavior as a clue, not as an official repair procedure you can rely on. A different device, partition map, or macOS build could behave differently.
The sequence, in outline, was:
- Attempt to delete the CoreStorage logical volume group using its identifier.
- Expect that the operation may fail after the logical volume is removed.
- Restart the Mac rather than repeatedly running destructive commands.
- Re-identify the physical disk after restart.
- Erase and format only after confirming you're targeting the intended disk and the data is backed up.
The original report used diskutil cs delete with a specific group identifier. Don't copy that identifier - it belongs to the example disk. More importantly, don't run deletion commands "to see if it works." Verify the target device and understand that deleting the logical volume removes access to its contents.
What the workaround does not solve
This sequence doesn't restore a CoreStorage volume, convert it to APFS, or recover files. In the reported case, attempts to convert the HFS+ volume to APFS failed, and the user rebuilt the storage from backups. So the workaround is for reclaiming a disk after you've decided to discard the old layout, not for migrating to a new one.
If the data still matters and you can't mount it read-only, the safer next step is to stop and look for a real recovery option rather than deleting the volume group. If you've already copied and verified the data, erasing and rebuilding may be the practical route. It's ultimately a trade-off between keeping a legacy format and getting the hardware back into service.
Conclusion
The key distinction is between a volume that's locked and a volume macOS can't manage through its normal storage tools. In the reported macOS 27 case, CoreStorage showed an unlocked, online volume, yet mounting, APFS conversion, and erasure still failed. A read-only mount_hfs command provided a way to copy data - but it didn't restore normal operation.
If you rely on CoreStorage or encrypted HFS+ storage, treat a tested backup as the first move, not an optional extra. Use read-only access to recover files, verify the copy, and only consider destructive erase steps if you're genuinely prepared to lose the original volume. That keeps the decision anchored to what matters most: protecting your data before you try to reclaim the hardware.