Long story short: ive noticed each time i create a secondary volume and removed it after some testing, the storage labeled 'Other Volumes' in the Disk Utility app has increased each time by half a gigabyte. I know for a fact that adding the new volume and removing it after the testing is what causes the 'Other Volumes' storage to increase by half a gigabyte each time, i just dont really understand why since im deleting the volume with all it's contents.

Originally the 'Other Volumes' was at 1.75GB before i did the first secondary volume, after removing the second volume it went up to 2.28GB; i just finished another test on another secondary volume and it went up again to 2.82GB for storage. I have a feeling that creating the new volumes and removing is what's causing the 'Other Volumes' to increase by half a gigabyte each time, but i want to know if there is some way to reduce it back down, preferably back to the 1.75 GB.

Is there a way to reduce the storage space of 'Other Volumes' without having to do something extreme?

  • Were these volumes used for installing a separate OS by any chance? Jul 15 '18 at 22:40
  • 1
    @ user3052786 yes, i had to re-install the current MacOS system(High Sierra 10.13.6) on both secondary volumes
    – no nope
    Jul 16 '18 at 0:01
  • 1
    what do you see when you run diskutil apfs list? Jul 16 '18 at 4:23
  • @user3052786 here's what i see when i ran that in the Terminal app imgur.com/a/9QEejNq
    – no nope
    Jul 16 '18 at 4:46
  • Creating two or more bootable volumes in the same container uses the same "Recovery" volume. Every user gets a UUID specific folder on Recovery (and Preboot for that matter), including a close to 500 MB BaseSystem.dmg. Those do not get deleted with the 2ⁿᵈ volume, but persist.
    – Redarm
    Jul 16 '18 at 11:03

Upgrades and deletions with subsequent recreation of volumes in a multi-volume container leave the container untouched and new (more) "file system UUID" specific folders are created for each volume in the shared "Recovery" volume. Those folders each include a close to 500 MB BaseSystem.dmg

These older folders are not cleared by the system.

To remove the older unused folders, make sure you are booted into a volume outside the container with the Recovery in question.
1.) Then first run the following command in Terminal (to be found in /Applications/Utilities/Terminal.app, or search for it via Spotlight)

diskutil list

...and press enter. This will show your disk identifier for "Recovery" in the output, which in your case is disk1s3

2.) Now mount the "Recovery" volume with this command:

diskutil mount disk1s3

...and press enteragain, which will mount "Recovery" in /Volumes/Recovery (press cmdshift. to make the invisible directory visible in Finder, if necessary).

Navigate to it and you can inspect the various folders for their content (e.g. the SystemVersion.plist). You can also delete them (I'd like to add that I do not suggest this though. Instead some feedback to Apple to clean up those older folders is what I did).

Since you want to keep the currently in use ones, you will have to find your volumes' current "file system UUID".

I'm using "Disk Utility.app" for that (/Applications/Utilities/Disk Utility.app): Select all your current volumes (one by one) and with one selected press cmdi to bring up the Info panel. There look for "file system UUID" in the left column and note its value.

Do that for all other volumes. If you've left the Finder window with the mounted Recovery open, you should now notice the ones you've found in Disk Utility also appear as folder names in the "Recovery" volume. Leave those alone.

Only delete the ones that currently don't correspond to an existing volume, as shown in Disk Utility and empty the Trash, if you use Finder.

The mounted "Recovery" will get unmounted the next time you restart, or you can just right-click the volume icon in Finder and eject it.

If you don't have a volume outside the container to boot into

You can also delete those folders from "Recovery" itself.
Boot into the "Recovery" volume by holding cmdR at startup.
Launch "Terminal" from the "Utilities" menu.

Now follow the instructions, as above, running the two commands mentioned.
1.) The first one...
diskutil list
...to find your Recovery's disk identifier (which should be different from the one found, when not booted into Recovery above).
It (the container in question) will look similar to this:

/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +62.5 GB    disk5
                                 Physical Store disk4s2
   1:                APFS Volume Installation1           23.8 GB    disk5s1
   2:                APFS Volume Installation2           12.2 GB    disk5s2
   3:                APFS Volume Preboot                 136.9 MB   disk5s3
   4:                APFS Volume Recovery                3.1 GB     disk5s4
   5:                APFS Volume VM                      8.6 GB     disk5s5

As you can see, "Recovery" shows its identifier disk5s4 to the right.

2.) Now run the second command with the found identifier, e.g.
diskutil mount disk5s4

Knowing your current file system UUID(s) from the first part of this answer, you can now delete the folders in Terminal.


Mount Recovery with diskutil mount and your own found disk identifier (bash-3.2# is just the command prompt Terminal displays):

-bash-3.2# diskutil mount disk5s4
Volume Recovery on disk5s4 mounted

Listing of all Volumes mounted under /Volumes with ls -al /Volumes:

-bash-3.2# ls -al /Volumes
total 8
drwxr-xr-x   8 root  wheel   340 Jul 22 14:17 .
drwxrwxr-t  16 root  admin   612 Jul  4 08:34 ..
drwxr-xr-x@ 31 root  wheel   992 Jul 16 22:09 AnotherVolume
drwxr-xr-x@ 30 root  wheel   960 Jul 21 10:59 Installation1
drwxr-xr-x@ 28 root  wheel   896 Jul  6 13:13 Installation2
drwxr-xr-x@ 42 root  wheel  1496 Jul 16 23:27 Macintosh HD
lrwxr-xr-x   1 root  wheel     1 Jul 22 14:15 OS X Base System -> /
drwxr-xr-x  11 root  wheel   352 Jul 17 13:53 Recovery

Changing the directory to /Volumes/Recovery with cd /Volumes/Recovery and listing its contents with ls -al. Those are two commands:

-bash-3.2# cd /Volumes/Recovery
-bash-3.2# ls -al
total 16
drwxr-xr-x  11 root      wheel      352 Jul 17 13:53 .
drwxr-xr-x   8 root      wheel      340 Jul 22 14:17 ..
-rw-r--r--@  1 _unknown  _unknown  6148 Jul 17 13:54 .DS_Store
d-wx-wx-wt   2 root      wheel       64 Jul 22 14:13 .Trashes
drwx------   5 _unknown  _unknown   160 Feb 24 14:22 .fseventsd
drwxr-xr-x  13 root      wheel      416 Feb  8 17:36 05971D12-C9A5-46FB-A70E-2BC0295FAE74
drwxr-xr-x  13 root      wheel      416 Jun  4 11:07 23379897-F07E-43A4-A993-03308663CD1B
drwxr-xr-x  13 root      wheel      416 Jun 24 10:40 59283231-6D51-412A-B100-D9E205805732
drwxr-xr-x  13 root      wheel      416 Jul 21 10:29 AA624F58-E5E8-425C-9698-C1B78C3B0992
drwxr-xr-x  13 root      wheel      416 Feb 25 17:06 ADDF591A-10FB-42C4-BDC5-C1C24E6D9217
drwxr-xr-x  11 root      wheel      352 Mar  1 14:19 C9D33FAC-742B-4F16-9DB3-6FFCB5E29DA9

Removing the first folder, named 05971D12-C9A5-46FB-A70E-2BC0295FAE74 (as found in the listing above), which I know to be unrelated to the currently in use ones with rm -r UUID and answering with "y" (yes) to the question to override:

-bash-3.2# rm -r 05971D12-C9A5-46FB-A70E-2BC0295FAE74
override rw-r--r--  root/wheel uchg for 05971D12-C9A5-46FB-A70E-2BC0295FAE74/boot.efi? y

Checking that it has been removed:

-bash-3.2# ls -al
total 16
drwxr-xr-x  10 root      wheel      320 Jul 22 14:18 .
drwxr-xr-x   8 root      wheel      340 Jul 22 14:17 ..
-rw-r--r--@  1 _unknown  _unknown  6148 Jul 17 13:54 .DS_Store
d-wx-wx-wt   2 root      wheel       64 Jul 22 14:13 .Trashes
drwx------   5 _unknown  _unknown   160 Feb 24 14:22 .fseventsd
drwxr-xr-x  13 root      wheel      416 Jun  4 11:07 23379897-F07E-43A4-A993-03308663CD1B
drwxr-xr-x  13 root      wheel      416 Jun 24 10:40 59283231-6D51-412A-B100-D9E205805732
drwxr-xr-x  13 root      wheel      416 Jul 21 10:29 AA624F58-E5E8-425C-9698-C1B78C3B0992
drwxr-xr-x  13 root      wheel      416 Feb 25 17:06 ADDF591A-10FB-42C4-BDC5-C1C24E6D9217
drwxr-xr-x  11 root      wheel      352 Mar  1 14:19 C9D33FAC-742B-4F16-9DB3-6FFCB5E29DA9

The Recovery does not have to be unmounted, as the reboot will unmount it anyway. Or, if you want to run First Aid in Disk Utility, unmount it with...
diskutil umount disk5s4
Again using your own disk identifier instead of disk5s4

If you have any questions, don't hesitate to ask.

  • im still completely nervous about using terminal commandst. . . have you removed previous UUID folders from volumes you deleted before in the past? im sure that this is how to do it and all, im just wondering if you've done it before
    – no nope
    Jul 20 '18 at 3:34
  • The two Terminal commands do nothing, but list your disks with a bit more information than Disk Utility and mount the Recovery. There is nothing to fear here. If there is anything to be apprehensive about, it's he deletion, but you can do that in Finder, if that makes you feel calmer. And yes, I've deleted a couple of those folders and the "Recovery" volume did shrink, pass a disk check and did boot afterwards ;)
    – Redarm
    Jul 20 '18 at 9:34
  • Just double check that it's not a currently in use "file system UUID" you are deleting (as described in the answer). That would prevent booting into the Recovery of that specific volume.
    – Redarm
    Jul 20 '18 at 9:49
  • Unfortunately when i tried to move the other two UUID folders from /Volumes/Recovery it said i dont have permission to access some of the files after I entered my admin password. . . what can i do now? I feel that theres something in the folders that I can delete to reduce the size, but can't delete the folder as a whole. Additionally i noticed when i mounted the /Volumes/Recovery i didnt see an option or Volume icon to unmount it in the Finder & Disk Utility; restarting my MacBook was able to unmount sucessfully as it said the path was not found
    – no nope
    Jul 21 '18 at 20:49
  • I was booted into a volume outside the container. I've updated my answer to reflect that.
    – Redarm
    Jul 22 '18 at 15:20

You must log in to answer this question.

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