macOS Sonoma has Dropbox Wrongly Reporting Not Enough Disk Space

[grtwd]

macOS 14.5 (23F79) on 2024 MacBook Air; Dropbox v200.4.7134

Dropbox has paused syncing, with the little "x" on the menubar icon. On clicking the icon, it says "not enough disk space".

However, this is not correct. In macOS Settings -> General -> Storage, it (correctly) states 1.1TB of 2TB used, and shows 0.9TB available. Once Dropbox is fully synced, at most 1.2TB will be used. I.e. there is plenty of space.

Interestingly, the terminal utility "du" also gets the wrong answer - du thinks 1.9TB of space is in use. Likewise "df" thinks there is less than 100GB free.

Examining the output of du, the problem appears to be double counting. Specifically, the directories in "/System/Volumes/Data/" and "/" contain exactly the same things, and are counted both times to reach the "du" total for disk usage of the drive. Indeed, if we examine the inodes in each place we see they are identical (inode number is the lefthand most number for each entry).

First for "/":

$ ls -i -lh /
total 17
11610314 drwxrwxr-x 91 root admin 2.8K Jun 1 21:16 Applications
11593762 drwxr-xr-x 75 root wheel 2.3K May 15 07:15 Library
1152921500311879701 drwxr-xr-x@ 10 root wheel 320B May 7 00:01 System
16815 drwxr-xr-x 6 root admin 192B May 15 07:15 Users
16825 drwxr-xr-x 4 root wheel 128B May 30 11:57 Volumes
1152921500312524757 drwxr-xr-x@ 39 root wheel 1.2K May 7 00:01 bin
16827 drwxr-xr-x 2 root wheel 64B Jan 12 19:18 cores
330 dr-xr-xr-x 4 root wheel 8.2K May 16 11:51 dev
1152921500312524834 lrwxr-xr-x@ 1 root wheel 11B May 7 00:01 etc -> private/etc
1152921504606781440 lrwxr-xr-x 1 root wheel 25B May 16 11:51 home -> /System/Volumes/Data/home
16824 drwxr-xr-x 4 root wheel 128B Mar 12 22:21 opt
11609361 drwxr-xr-x 6 root wheel 192B May 16 11:51 private
1152921500312524837 drwxr-xr-x@ 64 root wheel 2.0K May 7 00:01 sbin
1152921500312524940 lrwxr-xr-x@ 1 root wheel 11B May 7 00:01 tmp -> private/tmp
1152921500312524941 drwxr-xr-x@ 11 root wheel 352B May 7 00:01 usr
1152921500312558107 lrwxr-xr-x@ 1 root wheel 11B May 7 00:01 var -> private/var

while for /System/Volumes/Data:

$ ls -i -lh /System/Volumes/Data
total 3842
11610314 drwxrwxr-x 91 root admin 2.8K Jun 1 21:16 Applications
2645288 -rw-r--r--@ 1 root wheel 0B Mar 12 06:04 Icon?
11593762 drwxr-xr-x 75 root wheel 2.3K May 15 07:15 Library
17772 drwxr-xr-x 3 root wheel 96B Mar 12 22:20 MobileSoftwareUpdate
11604958 drwxr-xr-x@ 3 root wheel 96B May 7 00:01 System
16815 drwxr-xr-x 6 root admin 192B May 15 07:15 Users
16825 drwxr-xr-x 4 root wheel 128B May 30 11:57 Volumes
16827 drwxr-xr-x 2 root wheel 64B Jan 12 19:18 cores
3 dr-xr-xr-x 2 root wheel 1B May 16 11:51 home
15869 drwxr-xr-x 2 root wheel 64B Jan 12 19:18 mnt
16824 drwxr-xr-x 4 root wheel 128B Mar 12 22:21 opt
11609361 drwxr-xr-x 6 root wheel 192B May 16 11:51 private
17 drwxr-xr-x 2 root wheel 64B Jan 12 19:18 sw
11593309 drwxr-xr-x@ 5 root wheel 160B May 7 00:01 usr

Since the inode numbers (i.e. hard link references) are the same - look at Users, for instance, the biggest one - they are the same on the disk - yet they are being counted twice.

This is doubly curious since the macOS man page for "du" states:

The default behavior of du is to count files with multiple hard links only once.

Also: Directories having multiple hard links ... are counted a single time per du execution.

Something is stopping this inode deduping from working for du. Perhaps Dropbox is invoking du (or df), directly or indirectly, to calculate available space? Or perhaps it is doing the same system calls that du/df are doing, with the same result?

As an additional experiment, I called the C++17 function std::filesystem::space, which also returns the "wrong" answer (i.e. it thinks the disk is nearly full). Per the C++ std spec, std::filesystem::space simply calls statvfs. I'd guess this is what DropBox is doing too, directly or indirectly. On macOS, that is not sufficient.

If someone could suggest a workaround (other than simply freeing up even more space) - and/or refer this to the Dropbox development team - that would be great.

Thanks!

[Walter]

Hey @grtwd - sorry to hear you'e having issues with this and thanks for all the details you shared with us.

If this persists after rebooting your computer, could you please send us a screenshot of the app's exact status as shown in your menu bar?

Also, where is your Dropbox folder located as per the Sync tab in the app's preferences?

Any additional information or screenshots are more than welcome!

PS: Your post was auto-spammed by the system due to its length - apologies for the late response. 

[radical_exponent]

> In macOS Settings -> General -> Storage, it (correctly) states 1.1TB of 2TB used, and shows 0.9TB available.

One subtlety with the "Storage" view in macOS is that it doesn't count "evictable" items toward the used storage, despite them actually taking up space on disk. Evictable items are things that the OS can quickly decide to get rid of if it needs more space. Examples include Photos libraries backed up to iCloud, files in File Provider domains that are not marked "Available Offline" (possibly including some files in Dropbox, depending on configurations), and a variety of other things.

Dropbox uses `df` (or rather, an equivalent underlying syscall - statvfs) to determine available disk space on macOS. `statvfs` doesn't double-count hardlinks - but it also doesn't take evictable files into account like the system Storage view does. I'm not aware of any API in macOS that does give the same results as the Storage view.

When the system is in a critically low-disk-space condition, macOS will try to evict some of the evictable items. However, Dropbox can't tell ahead of time if continuing to sync will lead to extra space being made available (i.e. we don't have visibility into whether there are any evictable files, and how much space macOS could make available should they all be evicted) - so we need to be conservative. Otherwise, we'd risk filling up the user's disk completely and causing system stability problems (e.g. if it turns out there aren't any evictable items).

[grtwd]

Hi Walter -

Thanks for responding. My Dropbox folder location, as per Dropbox Preferences, is /Users/<username>/Dropbox, i.e. the default.

I have cleared the condition for now by reducing disk usage below 1TB (on the 2TB disk), but may be able to recreate it in future. The "not enough space" message was revealed when single-clicking on the menu-bar icon, where it would normally say "Your files are up to date".

[grtwd]

Hi RE -

Thanks for the super helpful comments.

I'm sure Dropbox is right not to actually fill up the disk but to try and anticipate the condition. Thanks for confirming that statvfs is used.

The idea that "evictable items" explains the issue is certainly interesting. However, note that I had 900GB available per macOS Settings -> General -> Storage. Is it really possible that I had 800/900GB of evictable items? Do you know where such items live on the disk - how could I check? Per Settings -> iCloud, I have 107GB of space used in iCloud - even if all of it is on the disk and "evictable", it doesn't account for the difference.

One other factor - using Dropbox Selective Sync, I removed from the sync a folder, generated on another machine, containing 154GB of file data in three files, the largest of which is 148GB. That was sufficient to get the sync to complete successfully. And now "df" says I have 610GB available - not the 89GB it said last night. I don't understand why the "df" result would improve so much from this one change. Is there some kind of very-large-file issue?

Re: statvfs, the macOS man page states: "...attempt to [provide] file system
statistics, but portable applications must not depend on this". Meanwhile the FreeBSD man page refers to statvfs output as "garbage" - macOS being derived from BSD of course.

https://man.freebsd.org/cgi/man.cgi?query=statvfs

So I don't assume statvfs is giving good answers...
To that point, if I look at the mount table, I see:

$ mount
/dev/disk3s1s1 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/disk3s2 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
/dev/disk3s4 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/disk3s5 on /System/Volumes/Data (apfs, NFS exported, local, journaled, nobrowse, protect, root data)
map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)

Also:

df -h /
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk3s1s1 1.8Ti 9.6Gi 610Gi 2% 404k 4.3G 0% /

And:

$ df -h /System/Volumes/Data/
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk3s5 1.8Ti 1.2Ti 610Gi 67% 3.1M 6.4G 0% /System/Volumes/Data

Not surprisingly, /System/Volumes/Data and "/" are not real hardlink duplicates - multiple hardlinks to a single directory are usually prevented - but they are different mount points to the same data.
I do still wonder if this is in fact confusing statvfs.

If you can suggest how I could investigate the "evictable files" theory further, that would be great.

Thanks again.

[grtwd · Accepted solution]

I was thinking further on your "evictable items" suggestions, and perhaps I have found the issue, or a big part of it anyway - Apple's Time Machine.

Last night I attached my laptop to my external Time Machine disk for the first time for about a week. This should have allowed TM to offload its local snapshots to the external disk. Just now, I also did (at the terminal):

sudo tmutil listlocalsnapshots /

sudo tmutil deletelocalsnapshots /

which deleted 15 local snapshots.

Now, macOS Settings -> General -> Storage says "1TB of 2TB used".
And statvfs says 990GB free. So they agree again!

It seems that TimeMachine local  (i.e. on-disk) snapshots were taking 800-900GB of space on the disk away from statvfs. Over the last week, there have been some large files copied to, and removed from the laptop disk, namely some KVM snapshots (40GB - 150GB). I can imagine that that caused these Time Machine local snapshots to become unusually large.

I have also adjusted macOS Settings -> General -> Time Machine -> Options -> Backup Frequency from "Automatically Every Hour" to "Automatically Every Day".

DropBox feature suggestion: In the event that DropBox thinks it does not have enough space to complete a sync based on statvfs - Figure out how much space is occupied by "evictable items" - Time Machine Snapshots, iCloud mirrors, the Trash folder - and let the user know if those elements are making the difference, and what to do about it - perhaps even offer to carry out the necessary actions for the user, if that's possible.

Thanks once more!

[Megan]

Hey @grtwd, thanks for keeping us updated!

Your comments on this have been quite helpful, and I will do everything I can to ensure that your voice is heard.

I'll forward your feedback to the appropriate areas so we can continue to improve.

Thank you!