Child Item

Dropbox app using a lot of memory in Linux Kubuntu 25.10

Hi everyone.

I have a Dropbox Plus plan with 2 TB of storage.

My system setup is the following:

AMD Ryzen 9 CPU
2 × NVMe SSDs (2 TB each), one dedicated exclusively to the Dropbox folder
32 GB DDR5 RAM (2 × 16 GB @ 6000 MHz)
Swap memory initially set to 16 GB (tested up to 128 GB)

The total amount of files stored locally is approximately 500 GB.
Recently, I encountered the following issue:

After making a minor change to the file structure (moving a folder of approximately 50 MB to a different path), the Dropbox daemon unexpectedly started a full re-indexing of all files.

Within a few minutes, the Dropbox client crashes. During this process, both RAM and swap memory are fully exhausted. I attempted multiple mitigations, including increasing swap memory up to 128 GB and reducing the synced dataset to approximately 200 GB, but the result is always the same: after several minutes, the Dropbox client crashes and syncing cannot complete.

This behavior makes it impossible to keep my files synchronized, despite having more than adequate hardware resources.

Is this a known limitation or issue with the Linux Dropbox client, and is there any recommended solution or workaround to prevent full re-indexing and client crashes in this scenario?

Thank you in advance for your assistance.

Kind regards,

Find more posts tagged with

Desktop

Linux

Insightful

Comments

Hannah

Hi there, @diml, thanks for bringing this to our attention.

The first thing that comes to mind when reading through your issue is the number of files in your Dropbox folder.

You said they were about 500 GB in size, but do you know the exact number? Could it be that they're more than 300K?

If so, can you use our selective sync feature, to reduce the number of files and see if it helps?

You can also take a look at this article for more info on your issue.

Let me know what you find.

ConnorBrinton

I also began experiencing the same problem over the past week. The Dropbox client can no longer index files without using absurd amounts of memory. Fortunately (or unfortunately), OOMs freeze my computer, so I can definitively say that Dropbox did not exhibit this behavior on December 24th, 2025 (when my computer restarted and did not subsequently OOM), but started exhibiting this behavior on December 30th, 2025 (when my computer restarted and then OOMed after 6 hours). My understanding is that Dropbox always reindexes files on-disk after a restart to make sure nothing changed while the Dropbox client was not running. On December 30th, the Dropbox process began continuously consumes more and more memory over about 6 hours until it crashes. During the 6 hours, Dropbox memory usage grows to about 16 GB of memory. Throughout all of this, the Dropbox tray icon says "Starting...", and no files are actually synchronized. Restarting just the Dropbox process results in the same outcome.

I do have a large number of files in Dropbox (~500k I think) and tried adjusting my selective sync settings to synchronize nothing (all folders unchecked). But even after restarting the Dropbox client, it continues to exhibit high memory usage and never finishes initial indexing. My understanding is that selective sync settings can't take effect until Dropbox finishes indexing the contents of the Dropbox folder (to prevent data loss from unsynchronized changes), so it seems like it's not helpful for this scenario.

I deleted a large number of redundant files in my Dropbox folder locally on my computer, reducing the file count from ~500k to 138,192. But this didn't help with Dropbox process memory usage.

I've also tried updating the Dropbox client with the `dropbox update` command, but I get an error when I try to do that:

```
$ dropbox update
Traceback (most recent call last):
File "/usr/bin/dropbox", line 1567, in <module>
ret = main(sys.argv)
^^^^^^^^^^^^^^
File "/usr/bin/dropbox", line 1556, in main
result = commands[argv[i]](argv[i+1:])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/bin/dropbox", line 851, in update
download()
File "/usr/bin/dropbox", line 293, in download
import gi
ModuleNotFoundError: No module named 'gi'
```

Right now Dropbox is unusable on my device as a result of this issue.

More information:

Operating system: Ubuntu 24.04
Data amount: 1.5 TB
Number of files in Dropbox: ~500k
Number of files on disk: 138,192
Filesystem: ZFS

Hannah

Hey @ConnorBrinton, sorry to see that you're also having this issue.

It does sound like the number of files might be causing the app to struggle a bit.

What do you see when hovering over your Dropbox icon?

Have you tried signing out of the Dropbox app and then back in, to see if it helps?

Здравко

ConnorBrinton wrote:
ModuleNotFoundError: No module named 'gi

Hi @ConnorBrinton,

You can try install missing module:

sudo apt install python3-gi

Does the same error appears after that? 🧐😉

Hope this helps to some extent.

diml

Hello , @Hannah

My dataset has been approximately 600,000 files for a long time.

I understand that the current Linux Dropbox client may not be optimized to handle datasets of this size (especially compared to Windows, where I do not experience this issue), and I can accept this limitation if necessary.

However, the main problem I observe is not only the number of files, but the behavior of the client when a full re-index is triggered.

At some point, the client unexpectedly started re-indexing all files, even though only a very small change had been made. When this happened, the client quickly exhausted system resources and crashed. Increasing available memory (32 GB RAM and up to 128 GB swap) did not prevent the crash.

I also attempted to significantly reduce the number of synced files using Selective Sync. Even when selecting a very small subset of folders, the client still appeared to:

re-index the entire local dataset first, and
only afterward start removing the excluded folders.

This makes Selective Sync ineffective in this scenario, because the expensive indexing process seems to occur before the exclusion logic is applied.

Based on this behavior, my assumption is that during a re-index event the client attempts to load a very large portion (or all) of the index into memory, which does not scale for large file counts, regardless of available RAM or swap.

From a design perspective, it seems that Selective Sync should ideally be applied before or during indexing, limiting the scope of the index to the selected folders only. In its current form, Selective Sync does not prevent the costly full re-index and therefore does not mitigate the crash scenario.

My goal in sharing this is to provide feedback on how the indexing process could potentially be improved for large datasets on Linux.

Thank you for your time and consideration.