nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Online-only files still use disk space and keep re-downloading on my Mac

Benjamin Gordon

MacBook Pro M1 Max, macOS 26.6.2 (25G83), Dropbox at ~/Library/CloudStorage/Dropbox. 2.58TB used of 3TB. Default sync state for new files is set to Online-only.

I have had large folders set to online-only for months. Dropbox reports them as online-only, but the disk space is never released. Sync and Storage still shows 1.39TB under "Available offline".

When I set them to online-only again, nothing changes. Restarting the app and restarting the Mac make no difference. Over time the local usage creeps back up rather than down.

So two questions:

Why does setting a folder to online-only not actually free the space on my disk?
What causes online-only files to download themselves again without me opening them?

Happy to provide logs or a diagnostic report.

Find more posts tagged with

Desktop

Storage space

Sync

Mac

Accepted answers

All comments

Hannah

Thanks for your post today, @Benjamin Gordon, I hope you're well.

Let's see what we can find out about this.

Can you please control-click on the Dropbox folder itself, then click on "get info" and send me a screenshot of what you see there?

Also, just to confirm, is the "Online-only files on Mac" setting enabled here?

As for the online-only files getting re-synced, do you perhaps have any third-party apps, like a security app or a third-party backup service or an app that monitors files in general? They could be accessing the files and re-downloading them.

Keep me posted.

Benjamin Gordon

Thanks Hannah.

For completeness: Dropbox 269.4.4231, macOS 26.6.2 (25G83), MacBook Pro M1 Max, 3.6 TB internal.

The "Online-only files on Mac" setting was off. I have now switched it on. Before I test it, can you tell me exactly what that setting does? Specifically:

Does it change how much disk space is actually used, or only how file sizes are displayed in Finder?
If it only changes the display, how does that help when the disk is genuinely full? My problem is not that Finder shows the wrong number, it is that the space is not available to other applications.
If it does affect real usage, what is the mechanism, and how long should I expect it to take?

On your question about third-party apps: yes. Carbon Copy Cloner mirrors two local folders into my Dropbox folder, and each run reads the destination to compare, which re-downloads online-only files. That accounts for the re-syncing. Backblaze is running but has a mandatory exclusion for ~/Library/CloudStorage, so it is not touching Dropbox.

On the disk space, here is my clearest test. On 8 September I unsynced about 2 TB using selective sync and left the machine idle for four hours. Free space did not rise, it fell, from 149 GB to 130 GB. fileproviderd and DropboxFileProvider sat at 200 to 240% CPU for the whole period with network throughput under 100 KB/s, and the app reported "No sync issues" throughout. The unsynced content was left behind locally in a folder named "projects (mirror) (Selective Sync Conflict)", which then started uploading to my account as a second copy of data already stored there.

One more data point that may help you narrow it down. Calling FileManager.evictUbiquitousItem on those same files does release the blocks immediately, and I have reclaimed several hundred GB that way. So the eviction mechanism itself works on this machine. Whatever the online-only control does, it is not that.

I am measuring with df -h /System/Volumes/Data and stat -f "blocks=%b size=%z", which is the filesystem's own accounting rather than anything Finder reports.

Happy to send logs, a diagnostic report, or Get Info screenshots of specific folders.

Hannah

Thanks for the reply and the additional info, it's really helpful.

About the setting I mentioned, it basically helps show which files actually take up space. Macs calculate the size of a file based on logical size rather than physical size, so the setting will help determine which files do take up space.

The setting takes a little time to update on the backend so you'll need to wait about 5 minutes, then restart your Dropbox app.

The app will then re-sync your files with the logical size set to zero bytes. This may take some time to complete depending on how many files you have in your Dropbox folder.

After the app finishes, please check the Dropbox folder's "get info" and let me know what you see.

Regarding the re-syncing of the online-only files and the selective sync conflicts you're getting, they do make sense to me, if you're using an app that clones your files in the Dropbox folder.

A selective sync conflict means that you have two folders with the same name in the same location, after removing the original through your selective sync settings.

If you temporarily disable Carbon Copy Cloner, does the issue persist?

Benjamin Gordon

She has confirmed your setting question herself: it makes Macs show physical rather than logical size. Display only, exactly as measured. And her CCC question is already answered, those tasks are disabled.

One warning before anything else: do not restart the Dropbox app right now. Your notes are explicit that a restart triggers a full re-index and starts re-downloading everything set to online-only, and on top of that rclone is currently uploading 1.15 TB. A Dropbox re-index in the middle of that is the worst possible timing. If you want to do her restart step, do it after the sync finishes.

Reply for her:

Thanks Hannah, that confirms what I measured: the setting changes reported size, not actual disk usage. I checked with stat -f "blocks=%b", which reads the filesystem's own block count, and a file was already at blocks=0before I enabled it.
I will hold off restarting the app for now, as I have a large upload in progress, but I will report back afterwards.
In the meantime I found the actual cause, and I think it will be useful to you.
Eviction fails on any file another process has open, and nothing ever retries it.
A controlled test on one folder of 11 items. Made available offline, everything materialised, 0.25 GB on disk. Then, with the folder open in Finder's column view, right-click, Make Online Only. 8 of 9 files evicted correctly to blocks=0 with flags compressed,dataless. One failed with "Unable to Remove Download" and stayed at blocks=96880.
lsof showed why:
COMMAND PID FD TYPE NAME
QuickLook 754 9r REG .../WIP/Clap Clap 24.07.25.wav
QuickLook had it open only because Finder was previewing it in column view. I ended that process and repeated the identical operation: the file evicted immediately, 0.000 GB on disk.
So online-only works. The problem is that a failure is permanent. The file stays fully on disk, the dialog names neither the file nor the process holding it, and nothing retries later. Across a large account, every folder you browse in Finder pins a few more files that never become dataless again. That is how I ended up with 1.39 TB reported as available offline in folders I set to online-only months ago, and why the figure creeps up over time rather than down.
On your Carbon Copy Cloner question: yes, that was the re-download source. It reads the destination to compare, which hydrates online-only files. Those tasks are now disabled and I have moved to a method that only ever reads the source.
Two things that would fix this properly: retry an eviction once the handle is released, and show which files failed rather than a single dialog naming nothing.

Benjamin Gordon

apologies - claude helped me write that email and i forgot to take out the top bit.

Jay

Hi @Benjamin Gordon, what you're describing sounds like the normal process for online-only files, in that if an existing process is still accessing the local file, then it can't be marked as online-only until the file is no longer in use.

As Finder was previewing the file, this would prevent Dropbox from returning the file to an online-only state. Currently, there isn't a method to 'queue up' the online-only status of a file once it is no longer in use.

The best way to ensure that files are online-only is to mark an entire folder as online-only (if you don't mind all the files in the folder not being local), or to ensure that all open processes aren't trying to access one of those files when you select them in bulk.

Benjamin Gordon

Thanks Jay, and that confirms the core of it: there is no way to queue the online-only status for later. That is the problem, not the momentary failure.

Two things on the workaround. I did mark the entire folder online-only, not individual files, and one file inside it still failed and stayed fully on disk. And "ensure no processes are accessing the files" is not something a user can do, because the process was QuickLook, invoked by Finder simply because the folder was open in column view.

So the sequence is: Finder previews a file, that pins it, the eviction fails, the dialog names nothing, and no one ever retries. Repeat that across a 2.58 TB account over months and you get the 1.39 TB I am reporting. Every folder I browse costs me a few more permanently local files, which is why the number creeps up rather than down.

Given there is no retry, two practical questions:

Is there any way to list which files failed to go online-only? Without that I cannot even find them, let alone fix them.
Is there a supported way to re-trigger online-only in bulk for files that failed? Re-selecting the folder does not appear to retry the ones already marked.

I have also filed this with Apple as FB24726630, since the eviction is handled by their File Provider framework and the missing retry sits on their side.

Jay

Currently, there isn't a method to detect the files that failed to switch to online-only, nor a method to re-trigger the request.

If you wish, you can suggest this change for others to vote on, so the dev team can look into this in future!

Benjamin Gordon

Thanks Jay. Can I check one thing about where the limitation actually sits?

When an eviction fails because the file is in use, macOS returns an error to the provider. That is presumably how Dropbox knows to show "Unable to Remove Download". If Dropbox receives that error, it already knows which file failed and why, so what prevents Dropbox from keeping those items in a list and retrying them on a later sync pass? As far as I can tell nothing in Apple's File Provider framework stops a provider retrying, so I want to understand whether this is a genuine platform limitation or a feature that has not been built.

Related: is there any setting that stops an online-only file being downloaded automatically when a process merely reads it? Backup tools, indexers and Finder previews all trigger this, so files I have set to online-only come back on their own. If there is no such setting, that is the other half of why the local usage climbs rather than falls.

Hannah

Hi again, Benjamin!

There's no list like the one you described, as there's no such feature available on the Dropbox desktop app.

And there's no setting to prevent online-only files from being downloaded by third-party apps at the moment either.

You can, of course, follow Jay's suggestion and post a feature request about this on our "Ideas" board.

I hope this clarifies things and if you need anything else, please let us know!

Benjamin Gordon

Thanks Hannah. Some follow-up, because I think the answer may sit on Apple's side rather than yours, and I would like to know whether a feature request is even implementable.

macOS provides setiopolicy_np with IOPOL_TYPE_VFS_MATERIALIZE_DATALESS_FILES, which lets a process set IOPOL_MATERIALIZE_DATALESS_FILES_OFF and "disable materialization of dataless files by the current thread or process". So as I read it, whether an online-only file gets downloaded is decided by the app doing the reading, not by Dropbox, and there is nothing you could expose as a setting that would override another app's reads.

Three questions:

Is that your understanding too, that the re-downloading is a File Provider behaviour controlled by the reading process, and therefore not something Dropbox can prevent?
For the missing retry on failed online-only conversions, is that a Dropbox gap or a File Provider limitation? macOS returns the failure to the provider, so I would expect Dropbox to be able to queue and retry, but I would rather hear it from you than assume.
If I post a feature request for a retry queue and a list of files that failed, is it actually implementable within File Provider, or would it be filed against something you cannot build?

I am asking because I would rather raise this with Apple as a platform issue than have a feature request sit on your Ideas board for years if it is not buildable.

Hannah

Happy Friday, Benjamin!

About your 3rd question, what I can say is that you can create an idea for any suggestion or feature you want, but we can't really know if these features can actually be implemented on File Provider.

About your other two questions, could you please give me some examples? Preferably with screenshots so we can get a visual of what you mean as well.