If you’ve ever run Disk Utility’s First Aid on an APFS volume, you’ll only be too familiar with status 65.

That error was from last year. Here it was two years ago, in February 2021:

Unmounting became a problem as long ago as 2017, although there were so many other bugs in Disk Utility then that even the simplest of tasks became long and tortuous.

If it’s any consolation, this doesn’t only happen to users, macOS does it to itself. When mounting volumes during startup, Disk Arbitration ‘probes’ each volume by running fsck on it. Look in the log and you’ll see plenty of entries like
17.890 fsck status 65 /dev/rdisk1s2
17.890 probed disk, id = /dev/disk1s2, with apfs, success.
where fsck has returned exactly the same error, surprisingly deemed by Disk Arbitration to be “success”. This doesn’t just happen occasionally: in one boot I’ve checked, it happened to a total of seven volumes, rdisk1s1, rdisk1s2, rdisk1s3, rdisk3s2, rdisk3s4, rdisk3s5, and rdisk3s6. Among those, rdisk3s5 happens to be the Data volume within the active Boot Volume Group, the most likely to develop errors, and the one the user is most concerned about.

It’s a strange world when the user is informed that status 65 indicates the check has failed, and is advised to back up the data on that volume, as if its total failure could be imminent, but Disk Arbitration considers it a success, and carries on regardless. No doubt it could be argued that First Aid is only run when a user suspects there might be a problem with a disk, while boot fsck checks are run routinely on disks that are expected to be healthy, and also get checked by APFS during its mount process.

However, the truth is that status 65 only means one thing: no fsck check has been performed because the check wasn’t even able to start. The disk’s status remains as unknown as it was before the check was attempted. The fact that happened to seven different volumes, all of them on internal storage, when starting up a healthy Mac Studio M1 Max with the latest release of macOS, is an admission of failure. Seven times over.

Because Apple has decided to keep APFS proprietary, and to release only very limited information about its internals, fsck_apfs and Disk Utility are its only maintenance and repair options. There’s nothing else to turn to when confronted by status 65. All the user can do is try manually unmounting the volume, or starting up in Recovery and checking from there.

Users have been driven to try identifying processes that might be blocking the unmounting of the volume(s) they want to check. Among the favourite contenders has been Spotlight indexing, and as a result some have taken to the largely futile task of killing Spotlight’s worker processes in an attempt to enable fsck to unmount a volume. The fact that fsck can fail with status 65 even during startup, and the observation that sometimes the Finder can unmount the volume successfully when fsck can’t, suggest a different and deeper cause.

The time has come to fix this pernicious and infuriating bug, so that Disk Arbitration no longer has to turn a blind eye to it, and vital disk tools can get on with their intended tasks. macOS 13.4 would be an excellent target, to ensure that when macOS 14 ships later this year, those long years of neglect can be put behind us. If that’s not possible, then Apple should release the source to fsck_apfs and let someone else fix it. We’ve had enough of status 65, thank you.