I'm running MacOS 13.2 on a mid-2014 MBP (11,3). I have a 2 TB external HD (Seagate Slim, spinning disk, GUID format) that was partitioned into two 1-TB volumes. Recently, using my main volume's Disk Utility, I deleted one volume and expanded the other to 2 TB. This action corrupted the drive: (1) while the partition map said the volume was 2 TB, Finder's info. window said its size was unchanged, at 1 TB; (2) Disk Utility's sidebar incorrectly depicted the volume as a separate device, rather than a volume on the existing device (it didn't indent it); and (3) First Aid failed.

I thus attempted to erase and reformat the drive. That also failed. I called AppleCare, and the advisor told me I should instead boot into the Recovery volume and try that operation from within its version of Disk Utility. That succeeded, on the first try. The disk is now behaving properly.


1) Why was the version of Disk Utility on the Recovery volume able to succeed where the standard version failed? The AppleCare advisor's confidence in the Recovery volume's version suggests this was not a fluke—i.e., that it's understood the latter is more powerful (and/or that it's somehow able to operate more powerfully from within the Recovery volume).

2) Given that the Recovery volume's version of Disk Utility appears to be superior, is it generally advisable for me to perform any future operations to modify or delete volumes using that version, rather than the one on my main drive?


Disk Utility is the same between the regular OS and maOS Recovery, but the environment it's running in is different, and that affects what it can do. The biggest constraint is that Disk Utility can't do much to things (e.g. volumes) that're in use. My guess is that some program had a file open on the volume, so it couldn't eject the volume, and therefore couldn't repair or erase it. In my experience, the background process that scans and indexes documents for Spotlight searches tends to be a culprit here.

In Recovery mode, almost nothing is running (including no Spotlight indexer!), so Disk Utility is much less likely to run into this sort of conflict.

BTW, there are some things that Disk Utility can do when running from the regular OS but not in Recovery. One I've run into is resizing the startup volume (if it's MacOS Extended format -- not sure about APFS). The reason for this is that the Recovery HD partition is right after the startup volume, so it needs to be moved if the startup volume is resized. But you can't move it if you're running from it!

  • "the Recovery HD partition is right after the startup volume." Interesting! And odd—given that Apple knows what you described, I wonder why Apple doesn't put the Recovery partition at either the beginning or end of the disk. [Or just at the end, if there are some circumstances in which the Recovery partition itself needs to be expanded.] – theorist Dec 24 '17 at 18:56
  • 1
    @theorist There are a couple of reasons to put it there. First, it's relatively easy to expand or shrink a volume at the end, but hard to move the beginning of a volume. When the installer runs on a volume that doesn't already have a Recovery HD partition, it has to shrink the volume to make room, and it's much easier to do that at the end. Second, there might be multiple startup volumes on the same disk, and each on needs its own Recovery HD partition, or there might be a volume that can't be shrunk at the end of the disk, or... it's simplest to put it next to the startup volume. – Gordon Davisson Dec 24 '17 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .