Dropbox - no "members.read"

You need to do the rclone config again with impersonate set. Can you try that?

:slight_smile: I did, .... but :frowning: at the of the process we end up in a Dropbox page error 400!!! - each time I try tp use impersonate for the config creating a new remote connection...

Same issue!
Ive tried every possible fixed in this thread...no dice!

Saddly, rclone is no longer working with Dropbox business. So bad...
And the issue is clearly coming from Dropbox themselves.
Shame on them...
:frowning:
Finally I have use Multcloud and setup an FTP on my NAS-Rpi . Multcloud does work very well with DropBox business Teams folders. So I use Multcloud for accessing Dropbox business and then backup all my Team folders to my NAS-Rpi via SFTP (SHH ftp actually). I did not want to do that as I have now to watch and protect some ports on my Rpi-NAS and on my router... but this is life...

Hi guys.
Recent additions to this thread - which I originated - looked alarming enough that I checked and can confirm: Dropbox business with rclone I use, ver. rclone-1.55.0.beta.5215.4b5fe3ada-1.x86_64 still work, all good since I set it up.
I cannot comment on "Teams" nor "sharing folders" - I don't use don't need it - but should one boil it all down to: rclone + dropbox(business) - I say all good.

I think the problem is with the impersonate flag?

If you aren't using that then it should work fine.

Does everyone agree with that?

One problem with me testing this is that I don't have access to a dropbox business account.

No, not for me, no 'impersonate' in my configs, which configs are rather simple.

This bit I use as args to 'rclone'
_GLOBAL="--verbose
--default-permissions
--allow-other
--dir-perms 0700
--file-perms 0600
--umask 0077
--dir-cache-time 168h
--timeout 1h
--vfs-cache-mode writes
--vfs-read-chunk-size 256M
--vfs-read-chunk-size-limit 2048M
--tpslimit 10"

and a config example, in its entirety:

[us-full]
type = dropbox
client_id =
client_secret =
token =
chunk_size

This works on both CentOS Stream and Fedora 33/34.
Now, snapshots of my Dropbox App's "Permissions" (being restrictive as I want it I need it)

1 Like

I propose - use those as a minimal starting base.
Obviously, rclone's setup steps will be important, connection, tokens, etc. but that above should work and if it does for you guys then later continue tweaking from there.

1 Like

I have this working since earlier, but when I just tried to setup a new app with the same app-settings, it did not work.
If I ran the config without the --dropbox-impersonate the App only gets added to my user-account, when I run it with the --dropbox-impersonate flag, I get an error as follows, and the app does not get added.
image

HOWEVER, when I in that Dropbox error URL manually add "+team_data.member" in the string of requested scopes it works!!!

So there is probably just this extra scope-section missing in the rclone URL generation for dropbox config.
version used that has this error:
D:\bin>rclone -V
rclone v1.55.0-beta.5334.ac7acb9f0.fix-dropbox-batch-sync

  • os/type: windows
  • os/arch: 386
  • go/version: go1.16.3
  • go/linking: dynamic
  • go/tags: cmount

EDIT:
same behaviour on this below version:
rclone v1.55.0

  • os/type: windows
  • os/arch: amd64
  • go/version: go1.16.2
  • go/linking: dynamic
  • go/tags: cmount

I just posted this in the other thread which hopefully will fix the problem if you do a rclone config reconnect with an impersonate email set. Can you give it a try?

v1.56.0-beta.5409.9b054c0cd.fix-dropbox-impersonate-scopes on branch fix-dropbox-impersonate-scopes (uploaded in 15-30 mins)

Yes, this build correctly requests the team_data.member scope in the generated URL, which makes the error go away.
With this I could successfully setup a new Dropbox remote with rclone towards a team-centric Dropbox app.

Great - thanks for testing

:+1:

I'll merge that patch now for v1.55.1 which we'll release in a few days

Here will be the beta for v1.55.1

v1.55.1-beta.5370.0d8c69b4e.v1.55-stable on branch v1.55-stable (uploaded in 15-30 mins)

If you wish I have a spare license for my db team, I could let you test with.

That is a kind offer. Would it have admin access? That is what I really need so I can try the impersonate stuff...

So I was going to make a new a thread, but this seems very much related. I will look into impersonate but I have no idea how to use it

What is the problem you are having with rclone?

Rclone about fails.
Further, union remote with mfs policy also doesn't work because of that.

I created Dropbox personal account in late 2016, yesterday I added Bussiness account with Advanced plan, registering using google account, which ended up connecting those accounts. I have no idea if this is related. I was really happy with performance and told my friend about it. He created brand new Business account, went for the same plan trial(I'm still on trial too), added rclone remote, then we tried to make union of those remotes and failed. Further digging points at rclone about remote: command being the simplest thing not to work.

What is your rclone version (output from rclone version)

rclone v1.55.1
- os/type: linux
- os/arch: amd64
- go/version: go1.16.3
- go/linking: static
- go/tags: none

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

Debian GNU/Linux 11 (bullseye) (x64)

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

Dropbox

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

rclone about dropbox3:

The rclone config contents with secrets removed.


[dropbox]
type = dropbox
token = {"access_token":"<removed>","token_type":"bearer","refresh_token":"<removed>","expiry":"2021-06-04T14:40:51.237435336+02:00"}


[dropbox2]
type = dropbox
token = {"access_token":"<removed>","token_type":"bearer","refresh_token":"<removed>","expiry":"2021-06-04T15:19:49.7544097+02:00"}

[dropbox3]
type = dropbox
token = {"access_token":"<removed>","token_type":"bearer","refresh_token":"<removed>","expiry":"2021-06-04T16:27:43.4041555+02:00"}
client_id = <removed>
client_secret = <removed>

dropbox works fine, dropbox{2,3} don't, in dropbox3 I created my own app with full permission scope, nothing changed

A log from the command with the -vv flag

rclone about dropbox3: -vv
2021/06/04 13:00:39 DEBUG : Using config file from "~/.config/rclone/rclone.conf"
2021/06/04 13:00:39 DEBUG : rclone: Version "v1.55.1" starting with parameters ["rclone" "about" "dropbox3:" "-vv"]
2021/06/04 13:00:39 DEBUG : Creating backend with remote "dropbox3:"
2021/06/04 13:00:40 DEBUG : 3 go routines active
2021/06/04 13:00:40 Failed to about: About call failed: about failed: missing_scope/.

In the meantime we tried adding Personal account to his Dropbox account, creating a brand new account, it didn't help, each new account encounters this issue yet my old one works fine. Our emails are all verified afaik, I can even upload files, just not check the remaining quota.
One more thing I guess, I use mail@gmail, friend used mail+dropbox@gmail, then I used mail+test@gmail, so I'm going to try this without the '+'.

edit:
mails without + still don't work
trying to impersonate my own mail results in:

2021/06/04 13:56:47 Failed to create file system for "dropbox4:": invalid dropbox team member: "<removed>@gmail.com": Error in call to API function "team/members/get_info": Your app is not permitted to access this endpoint because it does not have the required scope 'members.read'. The owner of the app can enable the scope for the app using the Permissions tab on the App Console.

This was fixed in the latest beta - you'll need to run with the beta then use rclone reconnect to remake the token.

You can probably go back to stable after that if you want.

1 Like

I can confirm, it works now.
Since I am generating tokens on another machine, I only needed to use beta on the one that runs rclone authorize "dropbox" command, pretty neat.
Thank you for your help!

1 Like

i had same issue & the solution above worked for me

1 Like

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