Subject: Abnormally Large Folders in /System/Volumes/Preboot (Cryptexes and UUID) Consuming ~48 GB

The only "safe" cleanup of System filespace I dare do on these new operating systems and APFS persistent storage (formerly called 'drives') is a Safe Boot. See the details here:

Start up your Mac in safe mode - Apple Support

That's about what my Preboot folder's size is on my Mac Mini M4 running Sequoia:

Since you're stuck with the 256GB boot drive the following is what I did with a 500GB drive iMac which I wanted to keep a minimum of 100GB of free space at all times for optimal system and application performance. :

1 - get an external SSD drive and format it APFS. (I recommend OWC (MacSales.com))..

2 - copy the Pictures, Movies, and Music folders to the external SSD.

3 - make sure the libraries in those folders work as expected on the external SSD.

4 - once confirmed the libraries are working OK on the SSD delete the contents of the Pictures, Movies an Music folders. DO NOT delete the folders themselves.

5 - rename the folders on the SSD to Pictures-2, Music-2 and Movies-2.

6 - remove the original folders from the Finder's sidebar and replace them with the -2 folders by dragging them from the SSD into the sidebar of an open Finder window.

That should free up space on your boot drive so you don't have to worry about the size of the Preboot folder or other System folders.

If you ever replace the Mini I recommend not getting storage less than 1 TB.

PS: And in reviewing my post for those god-forsaken auto-correct errors, I see that there's even another level of Finder confusion that I've missed. I was looking at the "on disk" size. But up at the top (and right next to it even) there's a 32 GB value. So perhaps that's the missing 18 GB. In addition to compressing system files, Apple also reuses identical low-level blocks. There are so many ways that Finder will mis-report storage values.

YondoValano wrote:

The current size is putting a significant strain on my 250 GB drive.

That's the problem. 250 GB is too small for any normal usage.

Why are these folders taking up so much space?

First I would ask how you arrived at those totals. Storage space is very difficult to calculate. The actual storage being used is often significantly different than what it appears to be.

What are the safe, recommended steps to resolve this and reduce their size?

None. You don't touch that stuff. You'll have to look for savings elsewhere.

YondoValano wrote:

I understand that for normal operation, installation, programming... and in general, comfortable use of the MacBook - it would be nice to have a version with +500GB. then I wouldn't care about a hidden directory weighing 50GB.

But that 50 GB is the operating system. You can't delete it or prune it down in any way. It is what it is.

I used the DaisyDisk program to find the files. Then I rechecked the data through the Finder, and it showed that the /Cryptexes folder was taking up much more space!

I don't know how DaisyDisk calculates those things and I know the Finder can't be trusted.

I'm currently developing my own storage management tool, so I deal with these issues quite a bit. (I already have a crude version in EtreCheckPro, but apparently no one has ever found it in the menu bar.)

I'm assuming your auto-generated tag "MacBook Air 13″, macOS 26.1" is correct. Here is what my similar computer says:

/tmp $ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:             Apple_APFS_ISC Container disk1         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         994.7 GB   disk0s2
   3:        Apple_APFS_Recovery Container disk2         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +994.7 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Data     758.7 GB   disk3s1
   2:                APFS Volume Macintosh HD            12.2 GB    disk3s3
   3:              APFS Snapshot com.apple.os.update-... 12.2 GB    disk3s3s1
   4:                APFS Volume Preboot                 8.1 GB     disk3s4
   5:                APFS Volume Recovery                1.2 GB     disk3s5
   6:                APFS Volume VM                      16.1 GB    disk3s6
   7:                APFS Volume shared                  13.0 GB    disk3s7

But that's low-level APFS disk partitions. We have to check how this relates to volumes:

/tmp $ mount  
/dev/disk3s3s1 on / (apfs, sealed, local, read-only, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk3s6 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse)
/dev/disk3s4 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
/dev/disk3s2 on /System/Volumes/Update (apfs, local, journaled, nobrowse)
/dev/disk1s2 on /System/Volumes/xarts (apfs, local, noexec, journaled, noatime, nobrowse)
/dev/disk1s1 on /System/Volumes/iSCPreboot (apfs, local, journaled, nobrowse)
/dev/disk1s3 on /System/Volumes/Hardware (apfs, local, journaled, nobrowse)
/dev/disk3s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse, protect, root data)
/dev/disk3s7 on /Volumes/shared (apfs, local, journaled, noowners, protect)
map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)

OK. This establishes that /System/Volumes/Preboot is verily device /dev/disk3s4. From the first list, we can see that this consumes 8.1 GB of storage.

Let's check and see what the Finder says:

OK. Finder's wrong. Most likely explanation is system file compression.

I have a different UUID folder than you do. That should be fine, it's a UUID after all. (Pro tip: they're not really universally unique. They are only unique to the device that generates them. If multiple devices are generating UUIDs, you can get duplicates.)

Again, not true. We know that this partition is only 8.1 GB in size. Yet Finder has just told us that it's 27.36 GB. It's not. There is a sibling folder for "Diagnostic Reports". Mine has 1107 bytes. I'm guessing that your folder has 18 GB.

You might be able to investigate that and figure out where your extra 18 GB is coming from. That's possibly fixable. But you're far more likely to be able to find and delete 18 GB from somewhere else on the drive.

My tool won't even let people examine these system folders. That's because it's always going to be some complicated rabbit hole like this. I don't want to deal with that. It's much easier to direct people towards their own data where they have a much greater chance of a successful outcome. It's way easier and less confusing.

I fundamentally agree that Apple shouldn't be consuming this much storage, shouldn't make things so complicated, and shouldn't be releasing software that's this buggy and confusing. But I can't fix that. And I sure can't stop people from applying each and every Apple update within seconds of it being released. Can't figure that out. The worse Apple's quality becomes, the more obsessively people have to have it NOW!!!!

YondoValano wrote:

Now the main question is: why do Finder, DaisyDisk and other utilities display virtual 27+ GB? Your explanation about APFS compression and block reuse is very logical. It seems that this is just a feature of displaying the "on disk" size vs. the "logical size" in APFS, which misleads users.

Because it's complicated. Those are all valid values, from a certain point of view.

I can't speak for DaisyDisk. Don't know anything about it. Can't speak for Apple either.

I can tell you what I do. On one level, I just try to ignore anything in that mess of Apple read-only, cryptographically sealed snapshot volumes. There's nothing that the user can do with those volumes in the first place, so why even show them?

Since I'm working on a storage management tool, I focus on the material conditions - the size on disk. If that differs from the display size, then I'll show the "logical" size in parentheses.

And my app uses an old-school pie chart. That can only ever total 100%. And if a sharp-eyed user notices that when they add up all the storage, it's more than they actually have on the drive, then hopefully they'll refer to the extensive help available that attempts to explain it.

And there are still a few cases where I do things differently for specific oddball cases. But that's me. I know people are likely to double-check these things, so I try to at least incorporate somehow the information that I know they will already have so they have some continuity of information. For example, when Apple reports a certain amount of storage as "available", then I show that, using the same "available" concept that Apple invented, even though I despise it. But I also show the actual amount of "free" storage, because that's the truth and the only value that matters.