You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
macOS Sonoma has Dropbox Wrongly Reporting Not Enough Disk Space
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...
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!
radical_exponent
Dropbox Engineer
Dropbox Engineer> 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).
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.
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!
