I'm new to rClone, and I need help understanding how to apply the setup instructions (here) to my target use case. Specifically, I want to approximate the functionality that the "Google Drive" client used to give me on Windows (I've migrated to Ubuntu). This amounted to an automated, bidirectional sync between 3 independent google drive accounts and their associated folders on my local machine:
A) Configure rClone with 3 separate "remotes". These remotes should be configured for "Service Account Support", each having some kind of "client_id" and "client_secret" stored in an rClone config file.
B) Learn how to use the "bisync" command to sync each of the three remotes to/from my local machine (I can probably figure that out).
C) Write a script, to be run periodically as a "cron job", that will automate the execution of the bisync commands from step B (I can figure that out too).
I'm in over my head with step A, particularly the steps regarding "Service Account Support". I got most of the way through the process for my first gmail account, but got that "clueless and probably breaking something" feeling and backed out.
Question 1) Does what I describe in steps A-C sound correct for my use case?
Question 2) Am I correct to go through the "Service Account Support" steps, given that I need to be syncing multiple accounts?
Question 3) Is creating my 3 remotes merely a matter of running "rclone config" 3 separate times, once for each gmail account?
Question 4) Is it safe to make all those changes at the Google Developer Console for each gmail account, and then store those "id" and "secret" keys in a config file? (cyber security isn't really a strong point for me)
I did find another topic on the forum (here) that asked a similar question, but the answer didn't quite give me what I needed. Obviously I'm green at all of this; I thank everyone for their patience, and for sharing some wisdom with the new guy.
Run the command 'rclone version' and share the full output of the command.
rclone v1.60.1
os/version: ubuntu 22.04 (64 bit)
os/kernel: 5.15.0-56-generic (x86_64)
os/type: linux
os/arch: amd64
go/version: go1.19.3
go/linking: static
go/tags: none
Which cloud storage system are you using? (eg Google Drive)
Google Drive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
so the first step is to create and test a remote for one service account file
following the steps at https://rclone.org/drive/#configuration
after that you should have a remote, which would look like
and when done, it should look something like
[gdrivesa]
type = drive
scope = drive
service_account_file = C:\data\rclone\rr\other\gdrive.sa\it.org.json
I suggest you start by setting up a single remote with plain default settings, that is no service account support and no personal client ID - just leave these fields blank when filling in the prompts in rclone config. That is follow the flow you see here: https://rclone.org/drive/#configuration
Later you should probably get your own Client ID to improve performance, but not needed initially. You can by the way use the same ClientID for all three - more about that later.
Note: service accounts and personal Client ID are two different things - for different needs/situations.
I am not sure bisync is the best choice for your situation. rclone mount may be a better choice, it is similar to the on-demand downloads of Google Drive - and often simpler to setup/maintain.
The best choice very much depends on your usage and whether you want to be able to use the data even when there is no network connection.
I suggest you/we quickly try each command on a small subfolder once you have made the first remote, that will illustrate better than I can tell in a thousand words.
Yes!
I however suggest you start by getting one account setup and thoroughly tested/tuned for your needs - and then do the remaining two. That will be very easy once you have completed the first.
I suggest we postpone this until we have solved all the above.
When we get to this, then I currently guess that it will be enough to create a personal client ID using your primary account and then use it for all the remotes. It is possible to encrypt the config containing tokens, client secrets etc. but again let's get something running first.
Wow what a great community! Thank you guys for your help! I've got a busy weekend with work, but as soon as that's done I'll focus on getting a single remote set up (per the excellent instructions on this site) without the "service account support" option. From there I'll run a few tests with the various options (rclone mount, etc), and report back with what I'm seeing.
Thanks again guys...I'll post back hear in a day or two.
Okay...much easier when I ignore the service account stuff. That config utility is very well written! I now have:
a) One working remote that has been tested with the moveto, mount, and bisync commands (all work great!). During the config process I chose "default" to a large number of options I didn't understand...no harm done as far as I can tell.
b) Along the way, I saw that the config menu changes after you create your first remote, opening up the option to create additional remotes. And so, I am good to create those other two remotes at any time.
c) I have studied the pros/cons of mount vs bisync, and I'm still trying to decide. I was always a bisync kind of guy before, but now Ole Frost has me reexamining the issue. In any case, I know either option will work.
d) I understand the point of making an personal client_id, and I understand the instructions for how to do so.
Much of the rest of my journey is not rClone specific (scripts and task scheduling). I do have a couple of lingering rClone questions:
Question 5) How do I decided when/if I need to set up Service Account Support?
Question 6) By my count, rClone will be locally storing client_id and client_secret (in the config file), as well as login credentials for my 3 gmail accounts (somewhere I haven't run down yet). Should I take measures to protect this information (some kind of encryption)...how do you guys handle that data?
You could consider it if you were setting up a script to easily access a lot of accounts (think 10+) or have a machine without web browser to do the authorization.
I cannot see any need in your scenario. I prefer keeping things simple and using the most walked trails.
The thing to really protect is the tokens in your config file, they give access to your Drives without needing login credentials or 2FA.
The most important question is if other have access to read your account or files, or you are afraid of malware stealing your config file. If so then you should definitively protect it.
I encrypt my config and use the --config-command and the Windows Credential Manager to protect my password. This way you can only see/use the config if logged in as me, not sure how to best protect it on Linux.