Dropbox Asymmetric Syncing

What is the problem you are having with rclone?

Asymmetric syncing issues that began recently without any known change to configuration. More specifically:

If I add/delete a file to my UnRAID Dropbox folder, it immediately appears/disappears in my PC's Dropbox folder and shows in the Dropbox website.

If I add/delete a file to my PC's Dropbox folder or website, it does not appear/disappear in UnRAID.

I made no changes since the initial configuration. It appeared to be working in both directions for a couple of weeks and only just noticed the issue recently. Just before this post, I disconnected RClone from Dropbox on Dropbox's side, obtained a new token, and reconnected RClone to Dropbox on the website. Behavior hasn't changed.

What is your rclone version (output from rclone version)

rclone v1.53.3

  • os/arch: linux/amd64
  • go version: go1.15.5

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Win 10 64

Which cloud storage system are you using? (eg Google Drive)

Dropbox

The command you were trying to run (eg rclone copy /tmp remote:tmp)

N/A

The rclone config contents with secrets removed.

Value "client_id" = ""
Value "client_secret" = ""
--------------------
[DropboxNate]
type = dropbox
token = {"access_token":"<removed>","token_type":"bearer","expiry":"0001-01-01T00:00:00Z"}
--------------------

A log from the command with the -vv flag

Sorry not sure what to do here.

What command are you running on the Windows box? A mount?

Just testing with Copy/Paste from desktop to Dropbox folder.

FWIW, with no changes, it seems like it's behaving normally again. I don't know what happened or why it lasted for a couple days, but seems to be going ok now.

I can't figure out where/how you are using rclone as there no mounts or any rclone commands.

My apologies... I'm using User Scripts in UnRAID to mount/unmount.


Mounting:

#!/bin/bash
#----------------------------------------------------------------------------
#first section makes the folders for the mount in the /mnt/disks folder so docker containers can have access
#there are 4 entries below as in the video i had 4 remotes amazon,dropbox, google and secure
#you only need as many as what you need to mount for dockers or a network share

mkdir -p /mnt/disk1/Nate/Dropbox
mkdir -p /mnt/disk1/Sarah/Dropbox

#This section mounts the various cloud storage into the folders that were created above.

rclone mount --max-read-ahead 1024k --allow-other DropboxNate: /mnt/disk1/Nate/Dropbox &
rclone mount --max-read-ahead 1024k --allow-other DropboxSarah: /mnt/disk1/Sarah/Dropbox &

Unmounting:

#!/bin/bash
#----------------------------------------------------------------------------
fusermount -u /mnt/disk1/Nate/Dropbox
fusermount -u /mnt/disk1/Sarah/Dropbox

So where is the issue? On one of the mounts you are running?

That does nothing unless you have a custom compiled kernel.

It was occurring on both mounts.

I'm honestly at a loss because it appears to be working normally now. But there were some days there where it behaved as described in the top post.

It seems to by syncing properly both ways now and I really haven't made any configuration changes aside from getting new tokens when trying to reinstall everything.

And thanks for the script tip, I'll get rid of the extraneous stuff.

So what is the flow? You copy it and run the mount and check? Dropbox isn’t a polling remote so you have to wait for the dir-cache time to expire to see any changes.

Flow:

  • Turn on UnRAID server

  • User Scripts runs RClone mount script

  • Turn on separate computer with Windows 10 with both Dropbox (installed on PC) and a mapped network drive to the share

  • Use Windows 10 and Dropbox normally and (since original config) see all files sync between DB and UnRAID share in nearly instantaneously.

What is a normal dir-cache time?

Regardless... again, not sure why it changed before but it appears to be working as intended right now.

It’s explained here.

Nothing had changed on that and it would always take the cache time to show up so depending if you got lucky on timing, it may appear to be lucky on when it shows up.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.