Transferring files between two users of the same domain


#1

Is there a method of transferring files from one user to another within the same domain?
I have a service account set up on the domain to impersonate the users and access their file.

However, each thread I’ve read mentions how it is only doable by downloading the files then transferring them from there. Or by sharing the files, adding to drive, then syncing them.

I’m trying to backup multiple accounts onto a singular account using something like this:
rclone copy --drive-impersonate user1@domain.com gdrive:/stuff/ --drive-impersonate user2@domain.com gdrive:/backups/date -I/

I know that exact command won’t work, but is there another way to do this? Even if it is not a one line solution, I just need to be able to backup without downloading TBs of data or sharing them.


#2

The files need to be copied somewhere. I think what you are asking for is for a command which will do a server side copy from one account to another.

Alas rclone doesn’t support this between accounts yet (it does within accounts), and if it did you’d quickly run in to the server side copy quota which is much smaller than the upload quota.

That command could be made to work with the latest beta. The latest beta includes a method for configuring all the config line parameters into the remote, so what you can do is edit your config file (use rclone config file to work out where it is) and duplicate the gdrive remove as gdrive_user1 and again as gdrive_user2. Then add into gdrive_user1

impersonate = user1@domain.com

and add impersonate = user2@domain.com for gdrive_user2

This should then make

rclone copy gdrive_user1:/stuff/ gdrive_user2:/backups/`date -I`

Work as you expect.

This will involve downloading the data then re-uploading it, but it will all happen on the fly so no local storage needed.

Does that help?


#3

Very helpful, thank you!

I’ll test this out when I get to work tomorrow, but it looks promising.


#4

Does the impersonate parameter in the config file override what is given in the command line?

For instance, if my rclone.conf contains [admin] with impersonate = admin@example.com
And a second remote, [gdrive], containing no impersonate parameter in the config.

If I were to run
rclone copy --drive-impersonate user1@example.com gdrive:/stuff/ admin:/backups/`date -I`
would the admin’s impersonate parameter be overridden by the new --drive-impersonate flag?


#5

Okay so I did a bit of messing around with the new impersonate parameter in the config.
It does look as though rclone will prefer to impersonate the user given in the command line rather than what is given in rclone.conf.

My rclone.conf looks like:


[admin]
service_account_file = /root/.config/rclone/rclone.json
impersonate = admin@example.com

[gdrive]
type = drive
service_account_file = /root/.config/rclone/rclone.json

And the commands I tested were:

rclone lsf admin:
rclone --drive-impersonate user1@example.com lsf admin:

Ideally these would’ve returned the same output, but they did not.
I can work around this by giving each user a remote, as you suggested in your first reply, but I am not sure if that will scale well with the scope of what I am attempting.

I’m going to take a look into making a bash script to:

  1. Takes my list of users as input
  2. Generates a new rclone.conf with the admin remote and all user remotes
  3. Runs the copy command for each user/admin pair.

#6

Flag values should override things in the config file as you might want to change them on the fly so this is expected behaviour…

All you need are two remotes… Let’s call them src and dst. You can then use environment variables to override impersonate for src and for dst separately.

Eg

export RCLONE_CONFIG_SRC_IMPERSONATE=user1@example.com
export RCLONE_CONFIG_DST_IMPERSONATE=user2@example.com
rclone copy src:path dst:path

That might help?


#7

That is perfect. I’m not the most familiar with this and this is much, much simpler than my solution.
Thank you


#8

Took me a minute to realize I didn’t need to edit my rclone.conf if using RCLONE_CONFIG__IMPERSONATE.

Couldn’t figure out why my impersonation was failing until I found out that that third word mattered and my config’s impersonation didn’t.