Sync Failure, DropBox

Hi, Today I cannot sync my 3 databases with DropBox as I have many times before. I get the following when DT is trying to fetch the remote store. (See attachment)
Screen Shot 2014-06-03 at 7.31.06 PM.png
I click “Allow” but it repeatedly keeps throws up another (same) message in Safari. I’m logged into DropBox, have plenty of room, and have no other problems with DropBox that I know of. It is an API Request Authorization. I’ve restarted my Mac. I’ve even deleted the synched files and tried to start over, but getting the same problem. Stumped. Any ideas?
TIA, Scott

I’ve just started getting this same error

dropbox v2.8.2
Devonthink pro 2.7.6

keeps repeating to ask me to confirm dropbox access, if I say yes, throws up an identical safari window again

There is something going on on Dropbox’s side of things.

I have just started to get this prompt for API Authorisation too, for each database that I’m trying to sync. Is there any more information that DEVONThink can give us? It means that sync can only be done manually now.

I am also getting the exact same problem:

  • repeated prompts for authorisation by the dropbox API.
  • in dropbox account settings, DT seems properly authorised.
  • in DT, no syncing occurs.

Has anyone found a solution for this problem ?


I have the exact same problem that arose in last 24 hrs, tried similar things to the person who initiated the post…any solutions yet?

I too am seeing the same problem. Current on versions for both DTO Pro (2.77) and Dropbox (2.10.28).

Just started getting the multiple “allow” screens today.

We’re getting a number of support tickets this morning for this issue. Nothing in the Dropbox code in Sync has changed in well over a year at this point, so it seems to be on Dropbox’s side. This is not the first time that it has happened and Dropbox seems to resolve it eventually.

EDIT: You might be able to force reauthentication with the following procedure:

​* Open /Applications/Utilities/Keychain

  • Search for OAuth
  • Delete the OAuth and OAuth Secret Tokens and quit Keychain Access.
  • In DEVONthink’s Preferences > Sync, delete the Dropbox location and re-add it.

Yeah this isn’t working for me…

Unfortunately this doesn’t seem to solve the problem…

It appears that some other developers are experiencing the same issues, going off a couple of threads in Dropbox’s discussion forums.

PS: They are aware there’s a problem, in general. Give them time.

PPS: Here’s another reason why you should consider if using a remote Sync location is optimal for your situation. (Just having a Dropbox account doesn’t make it optimal.) If you don’t need remote access, local syncStores are faster, more reliable, and under your control. Just something to consider.

What would be the Puddy tat’s meow would be if I could just btsync my existing store with the machines at home and not have to have a 3rd sync copy or 2 copies using a local store.

I was having this problem earlier today on both of my machines. Looks like it’s fixed now, at least to the extent that I was able to sync without any errors.


Have you tried this? It’s dangerous, since you’re explicitly bypassing the lockfile mechanism, but I can’t think of any technical reason why it wouldn’t work.

No I havent… it’s wishful thinking.

Well, it should be doable. The only tricky part is making sure that Machine A’s changes are completely synchronized to Machine B before Machine B does anything, but in my experience btsync is much, much better at indicating its status than, say, Dropbox, which is openly misleading (“Yeah, sure I’ve synced this whole folder. Suuuuuuuuuuuure…”).

Though I would still have concerns over network issues, I do like this idea better since it’s point-to-point between machines under my control. Interesting.

It’s unclear if it retains extended attributes though.
From their Forums: We plan to add extended attributes sync. Sorry, can’t provide ETA for now.

Working for me today (a day after I reported the problem)…nothing’s changed on my end so I’m also ready to say it’s a Dropbox issue

Yep. It was working again as of 11:15pm last night. And yep, it was their problem. :smiley: