0

I have an older MacBook Pro running OS X 10.13.6, the last version supported on the hardware. It has an SSD which was upgraded to APFS a while ago. A few months back, unfixable filesystem corruption developed (APFS - sigh). The total amount of used space on the filesystem was less than half the size of the drive capacity, so I decided to "fix" the corruption by using Disk Utility to create a new Volume within the SSD Container and copied the boot volume to this with Carbon Copy Cloner.

The new Volume approach worked. After a few months I decided I was satisfied that it was all working as expected and I didn't need the old Volume, so went to Disk Utility, selected the old Volume (at that point named "Old Mac HD") and used the "remove" button in the toolbar. This did get rid of the named Volume, but not the space it consumed. It still gets listed as "Other Volumes" in all GUIs (e.g. About This Mac and Disk Utility), but is NOT showing up in a list obtained from diskutil.

What gives? How can this exist as far as the GUI is concerned (and all free space reporting tools) yet not exist as far as the usually more accurate, lower level command line tool is concerned? More to the point, how do I actually delete this now-invisible, unmountable, unwanted Volume?

  • This is not the same question as those related to the VM volume, preboot (as far as I know) or how to resize containers (and attempting to resize the disk1 container to maximum with diskutil just, unsurprisingly, complains that there's no change in size being requested; the container is already at full size; it's a problem with the APFS volumes within it).

Thanks!

$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *960.2 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         960.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +960.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Preboot                 135.3 MB   disk1s2
   2:                APFS Volume Recovery                2.6 GB     disk1s3
   3:                APFS Volume VM                      8.6 GB     disk1s4
   4:                APFS Volume Macintosh HD            343.2 GB   disk1s5
$ diskutil apfs list
APFS Container (1 found)
|
+-- Container disk1 1AD6D668-918D-49EF-BCFB-D47BA2B128A5
    ====================================================
    APFS Container Reference:     disk1
    Size (Capacity Ceiling):      959987367936 B (960.0 GB)
    Minimum Size:                 777500598272 B (777.5 GB)
    Capacity In Use By Volumes:   692608249856 B (692.6 GB) (72.1% used)
    Capacity Not Allocated:       267379118080 B (267.4 GB) (27.9% free)
    |
    +-< Physical Store disk0s2 3443C641-413D-4232-8BB7-BBAAA805899D
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk0s2
    |   Size:                       959987367936 B (960.0 GB)
    |
    +-> Volume disk1s2 311035E5-562D-4703-A61D-B95DA47C6D14
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s2 (Preboot)
    |   Name:                      Preboot (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         135266304 B (135.3 MB)
    |   FileVault:                 No
    |
    +-> Volume disk1s3 51EC93A4-2585-4729-A550-14AEA58D3F79
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s3 (Recovery)
    |   Name:                      Recovery (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         2555449344 B (2.6 GB)
    |   FileVault:                 No
    |
    +-> Volume disk1s4 90162998-42CB-42A7-B0AC-3DEF8231D23C
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk1s4 (VM)
    |   Name:                      VM (Case-insensitive)
    |   Mount Point:               /private/var/vm
    |   Capacity Consumed:         8589959168 B (8.6 GB)
    |   FileVault:                 No
    |
    +-> Volume disk1s5 7ECF8825-686F-4D4B-A94A-10D7911C927E
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk1s5 (No specific role)
        Name:                      Macintosh HD (Case-insensitive)
        Mount Point:               /
        Capacity Consumed:         343116922880 B (343.1 GB)
        FileVault:                 No

Disk Utility screenshot

About This Mac screenshot

Volume info screenshot

  • You didn’t show the one item that will confirm things. diskutil apfs list shows how you use the raw space, but diskutil list will show the actual allocation. Probably 2/3 of the question can be removed, but let’s add the actual space allocation on the disks so we can confirm you just have a split allocation or need to resize the container for APFS as opposed to change things inside it. – bmike Apr 29 at 0:24
  • Also, why not back up and wipe the disk0 and restore? It doesn’t like you repaired things unless we find some diskAsB to delete for whatever values of A and B hold the missing space. – bmike Apr 29 at 0:27
  • @bmike - I couldn't see anything in "diskutil list" that was relevant; my question is how a volume can both be present according to the GUI yet absent according to APFS. Added anyway as edit to question. The filesystem corruption was entirely within the APFS volume (broken snapshots; Time Machine kept failing as a result). The cloned volume works perfectly. The old volume is deleted (or not!). Back up and restore will (A) require a 350G+ external drive, (B) a Thunderbolt enclosure else USB2 speeds and (C) causes some commercial software to need re-registration, which is sometimes very painful. – Andrew Hodgkinson Apr 29 at 4:41
  • And note, according to the GUI, Macintosh HD says it only has 200-odd GB free. There's 300-odd GB completely hidden, which is just showing as "other volumes" in the GUI and not showing at all in the CLI. As per original question - why, and how can it be fixed? Is it just flat-out a horrific bug in the 'remove volume' functionality? – Andrew Hodgkinson Apr 29 at 4:48
  • The diskutil list shows and confirms the entry point on the APFS listing. Without matching the container sizes, I had no confidence you were getting good data. It might be a bug or it might be just you need to wipe. Since I don’t want to answer that in comments, I’ll make a proper answer. – bmike Apr 29 at 11:49
1

You are correct. Your APFS container doesn’t show a volume that the GUI does, so I would primarily make sure you are backed up.

It could be a bug, so a reinstall of the OS or waiting for Apple to release and applying updates are your only path forward. It’s not super concerning, since you have a lot of room to grow and I’m presuming you have a valid backup of all the data.

This would be concerning if you can’t keep things backed up or don’t have a backup.

If it were me, I’d want to know if an erase fixes it, but your call when you do that or if you want to play the waiting game assuming there is a display bug instead of actual corruption that didn’t get resolved.

You must log in to answer this question.

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