Something taking up 90GB of storage in MacOS Catalina 10.15 Beta

I cracked the code!

Preface

This seems to have worked fine for me, but there are no guarantees. DO NOT PROCEED WITHOUT A BACKUP OF YOUR DATA. Then again, you know that, you voluntarily installed a beta operating system. 😜

The root of this issue seems to be a failure in deleting APFS snapshots made by Time Machine. Under healthy operation, old snapshots are deleted as necessary whenever new disk space is required. However, this process failed, as we'll see below.

Symptoms

1. Deleting files doesn't increase free space on the disk.
2. Daisy Disk reports a large "hidden space". Deleting a file of X bytes would increase the size of this "hidden space" by X bytes.

First try thinning

Firstly, I would try to manually thin out the Time Machine snapshots. This requests Time Machine to automatically clean out enough snapshots to free a desired amount of space, in this case, 100 GB.

$ tmutil thinlocalsnapshots 100g 1

If this succeeded, it should say something like

Thinned local snapshots:
com.apple.TimeMachine.2019-06-21-141250.local

Listing some number of deleted snapshots. However, I doubt this will help. If the system could get this to work automatically, I don't see why manually invoking it would help. But YMMV, so it's worth a shot.

Manual snapshot deletion

After some number of snapshots were deleted, some space was freed up, but not much. the issue is that deleting any number of snapshots won't matter if even one snapshot exists holding onto the same data. In my case, there were two snapshots remaining that persisted even after thinning:

$ tmutil listlocalsnapshotdates
Snapshot dates for all disks:
2019-06-11-214224
2019-06-21-233121

I tried manually deleting these:

$ sudo tmutil deletelocalsnapshots 2019-06-21-233121
Deleted local snapshot '2019-06-21-233121'

$ sudo tmutil deletelocalsnapshots 2019-06-11-214224
Deleted local snapshot '2019-06-11-214224'

The response says they were deleted, but they actually weren't:

$ tmutil listlocalsnapshotdates
Snapshot dates for all disks:
2019-06-11-214224
2019-06-21-233121

At this point, I start going the nuclear route: directly using diskutil to delete the APFS snapshots, without Time Machine's blessing to do so. First, I listed the APFS snapshots to see their UUIDs:

$ sudo diskutil apfs listSnapshots /System/Volumes/Data
Snapshots for disk1s1 (2 found)
|
+-- BFD78F4F-99BB-4D5B-AE16-5367DC9C615E
|   Name:        com.apple.TimeMachine.2019-06-11-214224.local
|   XID:         10440723
|   Purgeable:   Yes
|
+-- 611E5357-8D10-4ABE-95F3-BE98C2DFCA3F
    Name:        com.apple.TimeMachine.2019-06-21-233121.local
    XID:         10492913
    Purgeable:   Yes
    NOTE:        This snapshot limits the minimum size of APFS Container disk1

Then I tried deleting them manually:

$ sudo diskutil apfs deleteSnapshot disk1s1 -uuid BFD78F4F-99BB-4D5B-AE16-5367DC9C615E
Deleting APFS Snapshot BFD78F4F-99BB-4D5B-AE16-5367DC9C615E "com.apple.TimeMachine.2019-06-11-214224.local" from APFS Volume disk1s1
Started APFS operation
Error: -69863: Insufficient privileges

Strangely, even though I'm using sudo to run the command as root, I'm told I have insufficient privileges. This might have something to do with the read-onliness of the system volume, or to do with it being the actively booted volume, but I don't know.

Going nuclear

I loaded up into recovery mode, and went to the command line. From there, I did a similar process to try to delete the snapshots. However, this required first unlocking and mounting the relevant volumes.

1. Running diskutil list, I found that my data and system volumes were assigned the labels disk1s1 and disk2s5, respectively.

2. I think (I don't remember precisely) unlocked the volumes with:

   -bash-3.2# diskutil apfs unlockVolume disk1s1
   Password:
   -bash-3.2# diskutil apfs unlockVolume disk1s5
   Password:
   

3. Then I mounted them:

   -bash-3.2# diskutil mount disk1s1
   -bash-3.2# diskutil mount disk1s5
   

4. I listed their snapshots:

   -bash-3.2# diskutil apfs listSnapshots disk2s1
   Snapshots for disk2s1 (2 found)
   |
   +-- Name: com.apple.TimeMachine.2019-06-11-214224.local
   |   XID:  10440723
   |
   +-- Name: com.apple.TimeMachine.2019-06-21-233121.local
       XID:  10492913
       NOTE: This snapshot sets the minimal allowed size of APFS Container disk2
   -bash-3.2# diskutil apfs listSnapshots disk2s5
   Snapshot for disk2s5 (2 found)
   |
   +-- Name: com.apple.TimeMachine.2019-06-11-214224.local
   |   XID:  187251
   |
   +-- Name: com.apple.TimeMachine.2019-06-21-233121.local
       XID:  10492911
       NOTE: This snapshot sets the minimal allowed size of APFS Container disk2
   

5. I tried deleting the snapshots by their "XID", but that didn't seem to work for all of them, so I instead deleted them by name:

   -bash-3.2# diskutil apfs deleteSnapshot disk2s1 -name com.apple.TimeMachine.2019-06-11-214224.local
   Deleting APFS Snapshot XID 10440723 "com.apple.TimeMachine.2019-06-11-214224.local" from APFS Volume disk2s1
   Started APFS operation
   Finished APFS operation
   
   -bash-3.2# diskutil apfs deleteSnapshot disk2s1 -name com.apple.TimeMachine.2019-06-21-233121.local
   Deleting APFS Snapshot XID 10492913 "com.apple.TimeMachine.2019-06-21-233121.local" from APFS Volume disk2s1
   Started APFS operation
   Finished APFS operation
   
   -bash-3.2# diskutil apfs deleteSnapshot disk2s5 -name com.apple.TimeMachine.2019-06-11-214224.local
   Deleting APFS Snapshot XID 187251 "com.apple.TimeMachine.2019-06-11-214224.local" from APFS Volume disk2s5
   Started APFS operation
   Finished APFS operation
   
   -bash-3.2# diskutil apfs deleteSnapshot disk2s5 -name com.apple.TimeMachine.2019-06-21-233121.local
   Deleting APFS Snapshot XID 10492911 "com.apple.TimeMachine.2019-06-21-233121.local" from APFS Volume disk2s5
   Started APFS operation
   Finished APFS operation
   

6. Once this was done, I confirmed that the snapshots were gone:

   -bash-3.2# diskutil apfs listSnapshots disk2s1
   No snapshots for disk2s1
   
   -bash-3.2# diskutil apfs listSnapshots disk2s5
   No snapshots for disk2s5
   

7. And I confirmed that the space was in fact freed with diskutil apfs list.

8. I restarted, and my Mac was back to normal. The space of all of the files I previously deleted is now visible and available.

And they lived happily ever after...

Did you tell the installer to go ahead and copy any of your user data to the newly installed system? If yes, it's probably worth checking for expanded sparse files or sparse bundles/disk images. - Depending on the wisdom of the copying program, sparse files or bundles might have gotten expanded to their full glory, and take up "real" disk space now. Good candidates for sparse files on MacOS are sparse disk images, where the "room for expansion" got reserved during creation, but wasn't supposed to be taking up any space until filled with data. A simple copy can expand it as well...

To identify large files to inspect, you could use find:

• find / -type f -size +2G -ls would list every file exceeding a 2 GB threshold.

• if you want the output sorted by the size of those files, just add sort, and tell it to take the 7th column and display the results largest first (head further limits the output to the largest 20 of the bunch, to keep you from getting spammed):

  find / -type f -size +2G -ls | sort -k7 -r |head -20

Given the amount of space you're wondering about, chances are that this search would pop up the culprit. If it's something that was copied over from another installation, you could compare the space the file "really" takes up on disk by running du -sh </path/to/file> for both files. If it's smaller on the source side, re-copy it with a tool that keeps sparse files intact.

To identify by directory:

If you're more of a visual person, you could use a graphic tool to display the space taken up by directories, and drill down from there:

• Disk Inventory X has been around forever, is free, and still actively maintained, while
• Daisy Disk offers a modern interface, and a "free trial".

Unfortunately (as you've experienced) those tools only give a vague idea where large files may lie in hiding, but those can often serve as starting point for the commandline-based examinations.

If you prefer to examine the directories from the command line, you can find the large ones using find and du:

• find / -type d -exec du -sh {} \; |grep "G " ("G " needs to be entered as Gcrtl-v<tab> to search for G<tab>) will list out all directories which are at least one G in size. Note that this will sum up nested directories several times depending on their nesting level (it will sum up /usr, /usr/local /usr/local/bin /usr/local/etc without trying to optimize the process).

It'd be interesting to hear back from you when you've identified the culprit!

@Alexander @Mane Manero As the tmutil usages shown:

Usage: tmutil deletelocalsnapshots [<mount_point> | <snapshot_date>]

You should feel free to delete snapshots using this command without sudo and recovery mode:

➜  ~ tmutil deletelocalsnapshots /System/Volumes/Data
Deleted 5 Time Machine local snapshots for volume group containing disk '/System/Volumes/Data'
com.apple.TimeMachine.2019-10-09-234112.local
com.apple.TimeMachine.2019-10-09-200334.local
com.apple.TimeMachine.2019-10-09-220434.local
com.apple.TimeMachine.2019-10-09-210802.local
com.apple.TimeMachine.2019-10-10-162541.local