Identical config and mount scripts creates separate backends on google drive (crypt)

What is the problem you are having with rclone?

I am trying to mount the same Google Drive crypt mount by copying the config across machines. But sometimes, on some machine, rclone creates a diffferent backend directory right next to the previous one.

Like this. And I have the same username, UID and GID in both the machines but the backends change.
image

How do I make sure that across machine, rclone uses the same backend directory? How is this option specified, and what is the default evaluation method? It works between 2 machines, but not the third.

two are amd64 but third one is arm64 if it matters.

Please help !

Config file was copied across machines. But two different backends are being used, and I have no idea how to manually specify which one to use.

Run the command 'rclone version' and share the full output of the command.

rclone v1.53.3-DEV

  • os/arch: linux/arm64
  • go version: go1.18.1

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)

rclone lsd crypt_remote:path -vvv 

The rclone config contents with secrets removed.

[drive_remote]
type = drive
client_id = ###############
client_secret = ########################
scope = drive
token = {##########}
team_drive = 

[crypt_remote]
type = crypt
remote = drive_remote:path
password = ##############################
password2 = ######################
filename_encoding = base64

A log from the command with the -vv flag

With the identical configs, one machine produces:

$ rclone lsd crypt_remote:path -vvv 

2023/07/23 17:54:09 DEBUG : rclone: Version "v1.53.3-DEV" starting with parameters ["rclone" "lsd" "crypt_remote:path" "-vvv"]
2023/07/23 17:54:09 DEBUG : Using config file from "/home/user/.config/rclone/rclone.conf"
2023/07/23 17:54:09 DEBUG : Creating backend with remote "crypt_remote:path"
2023/07/23 17:54:09 DEBUG : Creating backend with remote "drive_remote:rcl51a8sceklgi0963###########
2023/07/23 17:54:09 DEBUG : Google drive root 'rcl/51a8sceklgi0963###########': root_folder_id = "0AAhfr####k9PVA" - save this in the config to speed up startup
2023/07/23 17:54:11 DEBUG : 4 go routines active  

and another produces

$ rclone lsd crypt_remote:path -vv
2023/07/23 18:02:28 DEBUG : rclone: Version "v1.62.2" starting with parameters ["rclone" "lsd" "crypt_remote:path" "-vvv"]
2023/07/23 18:02:28 DEBUG : Creating backend with remote "crypt_remote:path"
2023/07/23 18:02:28 DEBUG : Using config file from "/home/user/.config/rclone/rclone.conf"
2023/07/23 18:02:28 DEBUG : Creating backend with remote "drive_remote:/rcl/KFSOMdSs############"
2023/07/23 18:02:28 DEBUG : drive_remote: Loaded invalid token from config file - ignoring 
2023/07/23 18:02:28 DEBUG : Saving config "token" in section "drive_remote" of the config file
2023/07/23 18:02:28 DEBUG : drive_remote: Saved new token in config file
2023/07/23 18:02:28 DEBUG : Google drive root 'rcl/KFSOMdSsJ########': 'root_folder_id = 0AAhfrocRgNXeUk9PVA' - save this in the config to speed up start up
2023/07/23 18:02:29 DEBUG : fs cache: renaming cache item "drive_remote:/rcl/KFSOMdSs############" to be canonical "drive_remote:rcl/KFSOMdSs############"
2023/07/23 18:02:29 DEBUG : fs cache: switching user supplied name "drive_remote:/rcl/KFSOMdSs############" for canonical name "drive_remote:rcl/KFSOMdSs############
NWu4g"
-1 2023-06-03 03:11:32        -1 dir1
-1 2023-07-21 20:06:46        -1 dir2
-1 2023-06-03 17:19:37        -1 dir3
2023/07/23 18:02:29 DEBUG : 6 go routines active

As you can see, it produces different results as the drive backend directory is different.

Solution - It was version !

I was able to solve the problem while completing the question. I decided to post the question anyway in order to document my experience.
I noticed that the two machines where it worked had closer version numbers, and this being ARM, had an older version. Updating to the newest version using rsync installation script solved the problem.


Regarding Username/UID

Regarding this issue, I remember having the exact same problem when the username / UID were different. I had mitigated it by changing the username and UID to be identical, if this is a known issue, then what is the proper way to make a single config accessible to multiple users?

Make sure password and password2 are the same and the encoding methods are the same. In your example it looks like one is using base64 and the other isn't (and therefore is using the default base32) but I can't be 100% sure about that.

Versions of rclone, architectures (arm64 vs amd64) and uids shouldn't matter.

Oh and the case of the directories needs to be the same, so directory and Directory will map to different encrypted strings.

Make sure password and password2 are the same and the encoding methods are the same. In your example it looks like one is using base64 and the other isn't (and therefore is using the default base32 ) but I can't be 100% sure about that.

If the config works in one machine, it is supposed to work well in another, right?

Versions of rclone, architectures (arm64 vs amd64) and uids shouldn't matter.

I had the mount command as a script, without any change to that, updating the rclone version fixed the problem with the backend directory. Maybe the DEV builds have any problem??

Oh and the case of the directories needs to be the same, so directory and Directory will map to different encrypted strings.

Yes, of course, I had gone as far as to make the mount destinations identical. Updating to the new version made the difference. I will keep an eye while using, I will come back to this thread if I can successfully replicate the problem again.

Identical configuration do work across machines.

That though doesn't work on 1.53 as that's an ancient version of rclone, which was the problem.

Well spotted :slight_smile:

Ah, got it, the old version of rclone was just ignoring that config !

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