Dropbox Cloud Sync PULL Task Failure (Electric Eel 24.10.2)

TrueNAS General
, ,
1

First time posting, first time install of TrueNAS Scale.

I have configured a PULL in Cloud Sync tasks to copy all of our files to a dataset on our pool. (EDIT: Pulling from Dropbox to our local TrueNAS server.)

For the first run, I set it to ‘COPY’, and it copied almost all of the ~28TiB, however it failed at the end, reporting ‘too_many_requests/’ errors.

I tried to re-run the task again several times, changing it to ‘SYNC’, as well as decreasing the number of simultaneous transfer threads (I set it to a custom value of ‘1’ the last time).

Each time I get the same series of errors, which you can see in the following excerpt provided by the TrueNAS GUI:

2025/02/22 08:58:34 INFO :
Transferred: 0 B / 0 B, -, 0 B/s, ETA -
Checks: 26 / 26, 100%
Elapsed time: 2.0s
2025/02/22 08:59:38 INFO : 01 COMPANY FOLDERS/Administrative Files/Financial/Fee Schedule/Funeral or Memorial/ShadowPower - Celebration of Life Pricing Guide (1).pdf: Copied (new)
2025/02/22 09:00:23 NOTICE: too_many_requests/…: Too many requests or write operations. Trying again in 15 seconds.
2025/02/22 09:00:23 NOTICE: too_many_requests/: Too many requests or write operations. Trying again in 15 seconds.
2025/02/22 09:00:23 NOTICE: too_many_requests/.: Too many requests or write operations. Trying again in 15 seconds.
2025/02/22 09:00:23 NOTICE: too_many_requests/…: Too many requests or write operations. Trying again in 15 seconds.
… 2067 more lines …
2025/02/22 18:17:04 INFO : 02 PROJECT FOLDERS/02 INACTIVE/03 DOCUMENTARY/My Story Series/Ari’s Story/Production: Set directory modification time (using SetModTime)
2025/02/22 18:17:04 INFO : 02 PROJECT FOLDERS/02 INACTIVE/03 DOCUMENTARY/My Story Series/Ari’s Story: Set directory modification time (using SetModTime)
2025/02/22 18:17:04 INFO : 02 PROJECT FOLDERS/02 INACTIVE/03 DOCUMENTARY/My Story Series: Set directory modification time (using SetModTime)
2025/02/22 18:17:04 INFO : 02 PROJECT FOLDERS/02 INACTIVE/03 DOCUMENTARY: Set directory modification time (using SetModTime)
2025/02/22 18:17:04 INFO : 02 PROJECT FOLDERS/02 INACTIVE: Set directory modification time (using SetModTime)
2025/02/22 18:17:04 INFO : 02 PROJECT FOLDERS: Set directory modification time (using SetModTime)
2025/02/22 18:17:04 ERROR : Local file system at /mnt/deathstar/shadowpower/ShadowPower Dropbox: not deleting directories as there were IO errors
2025/02/22 18:17:04 ERROR : Attempt 3/3 failed with 1 errors and: multi-thread copy: failed to open source: too_many_requests/
2025/02/22 18:17:04 INFO : Dropbox root ‘’: Committing uploads - please wait…
2025/02/22 18:17:04 Failed to sync: multi-thread copy: failed to open source: too_many_requests/

When looking at the full log, there are hundreds of lines that have the ‘NOTICE: NOTICE: too_many_requests/: Too many requests or write operations. Trying again in 15 seconds.’

They appear to all be associated with a single file – it is a large video file, however there is nothing unique about the filename, and others in the same folder with same naming conventions have been successfully transferred.

Hopefully this is enough info to get things rolling, please let me know if you need anything more!

2

Hi @surferrosa!

rant about Dropbox

I do consulting for a small company.
12 years ago we decided to go with Dropbox as our Cloud Storage provider, because it was the easiest to use, especially with external people.

Even though they offered “unlimited versions” in the beginning (now it is down to 180 days) we never fully trusted them. Try to restore a state from a file a few months ago and that file was changed multiple times a day. You better write a browser script that clicks to load the next 10 versions and then waits multiple seconds for it to load :grimacing:

We wanted our own backup solution.
We used TrueNAS and CloudSync to sync the data to our local TrueNAS on a weekly basis.
This worked for years without any problems.

In recent years, Dropbox search for new ways to make money. They implemented features that nobody wanted (Password, Pages, many more), in the hope to grow. The experience of just using Dropbox got way worse because of it.

Performance was never great and they used compression, LAN sync, not really deleting files and many other things to penny pinch the last drop out of their slow servers. API calls for TrueNAS were also extremely slow, but fast enough to get the sync job done in 4 days.
We are talking here about 5TB of data and roughly 900k files.

TLDR: In recent weeks, they turned the enshittification nob to 10. We now run into a rate limit when TrueNAS tries to list the files. Sync is no longer possible for us via API.

3

Definitely catching the distinctive scent of enshittification lately, in many places.

1 Like
4

I re-attempted the sync with the file in question excluded (by excluding the entire folder it was in.) It was successful.

The file is a large DNxHR video file (~950GB). It is in a folder with other files that share the same syntax, so that would seem to rule out invalid characters, etc.

Just to give a few details, if they help, the directory+file name:

02 PROJECT FOLDERS/02 INACTIVE/03 DOCUMENTARY/My Story Series/Ari's Story/Production/ASSETS/Location Footage (Audio and Video by Date)/9.19.21/Location A-Roll/NINJAV_S001_S001_T109.MOV

and syntax I used in the ‘exclude’ field of my Cloud Sync Task:

02 PROJECT FOLDERS/02 INACTIVE/03 DOCUMENTARY/My Story Series/Ari's Story/Production/ASSETS/Location Footage (Audio and Video by Date)/9.19.21/Location A-Roll/**```
1 Like
5

This just started failing for me too in the last week. For months I’ve had a nightly one-way pull to a read only backup. I have a ~1.1TB dropbox account.

I was thinking maybe to divide the sync job into multiple jobs that run over a couple hours to reduce the number of files at once. Dang, this was so easy as it was…