Share Encrypted Folder Between Accounts

Two Google Drive accounts, one has an encrypted folder that has been shared to another Google Drive account and shows up quite clearly in the shared section or by using the appropriate flag. Duplicated remote names are not allowed so:


How can I set it up so the encrypted directory can be read decrypted on both Google drive accounts?


1 Like

Welcome to the forum :smiley:

  • What type of drive the drive with the encrypted folder? (regular personal or teamdrive aka shared-drive)
  • What type is the other, the one you want to share to?

The procedure will vary a little bit depending on what you answer.

Security note:
Do you trust the users of both accounts? Because you will necessarily have to share the encryption key for the data for the second disk to be able to read it there.If you can not trust completely - we may have to consider using a different crypt key on the shared data than on any private and sensitive data.

Regular Google drive, not Team, and yes, I do trust my siblings - I think... LOL

Yes, for now the same key. It would be interesting to be able to have a different key, but that is not what I am looking for here. I imagine that would take quite some work to make multiple keys be valid at the same time.


Yea, multiple valid keys to the same encrypted data isn't a thing.
But of course you could always have one personal storage, and one shared (but still encrypted) one.
But you kind of have that already I guess, since you only share the shared folder.
Let's start with the shared key scenario then.
All you really need for that is

  • Setting up the Gdrive remote (which it sounds like you have already done)
  • Adding a crypt remote
  • chaining them together

Here is what the setup would look like in the config

type = drive
scope = drive
token = {"[REDACTED] - created by rclone config"}
root_folder_id = [REDACTED] - created by rclone config

type = crypt
remote = Gdrive:
filename_encryption = standard
directory_name_encryption = true
password = [REDACTED] - created by rclone config
password2 = [REDACTED] - created by rclone config

Note the highlighted line. The GdriveCrypt: points to the Gdrive: . Thus if you mount or otherwise access GdriveCrypt: the data going up or down will go through the encryption layer. (it is still possible to access Gdrive: directly if you wanted that for whatever reason, but already encrypted files would look like nonsense.

Additionally you will need to:

  • make sure the crypt-key is the same on both setups. Of course if there is already data you wish to keep you must use the same key you used to encrypt it.
  • use the --drive-shared-with-me flag on the recipient's machine (the person whom the folder is shared to)

Depending on preference, the recipient may find it easiest to make 2 mounts. One with --drive-shared-with-me and one without. Because without the flag you only work in your own area, but with it on you only work in the shared area. Shared folders are a little bit clumsy like that and it's not really possible to show all-in-one unless you use a more complex Union setup.

Does this cover most of what you need? Feel free to ask followup questions if I need to elaborate on something :slight_smile:

Thanks, I will try that.

  1. Setting that up, the normal way, I do not get any value as the root_folder_id, as I used the default.

  2. Using that exact configuration, on a second Google account that I have, I get the Gdrive view and the shared with me files just fine, but get an empty directory when using GdriveCrypt. Since I am trying this on my own machine, I created and used a different config file, and this is the log result of when it starts to load. Maybe you can see the error. The two sections as shown in your post above, save the root_id, are the only items in the config file. This is with mount:

C:\mylogon>rclone --config /mylogon/rclone.conf mount GdriveCrypt: Z: --drive-shared-with-me -vv
2019/10/30 00:28:15 DEBUG : rclone: Version "v1.49.5" starting with parameters ["rclone" "--config" "/mylogon/rclone.conf" "mount" "GdriveCrypt:" "Z:" "--drive-shared-with-me" "-vv"]
2019/10/30 00:28:15 DEBUG : Using config file from "C:\mylogon\rclone.conf"
2019/10/30 00:28:15 DEBUG : Encrypted drive 'GdriveCrypt:': Mounting on "Z:"
2019/10/30 00:28:16 DEBUG : Adding path "vfs/forget" to remote control registry
2019/10/30 00:28:16 DEBUG : Adding path "vfs/refresh" to remote control registry
2019/10/30 00:28:16 DEBUG : Adding path "vfs/poll-interval" to remote control registry
2019/10/30 00:28:16 DEBUG : Encrypted drive 'GdriveCrypt:': Mounting with options: ["-o" "fsname=GdriveCrypt:" "-o" "subtype=rclone" "-o" "max_readahead=131072" "-o" "attr_timeout=1" "-o" "atomic_o_trunc" "-o" "uid=-1" "-o" "gid=-1" "--FileSystemName=rclone" "-o" "volname=GdriveCrypt"]

When I try using ls it states no file found, which is exactly what I see, no files.


As discussed in a different thread, the passwords for the crypt are the same as the crypt on the source/master account.

I also tried passing a directory, and it too, displayed without encryption, but not with. Lots of garbage looking names, due to the encryption.

So there are encrypted files there when you look without crypt- but looking with crypt they can not be seen?

Usually this means the crypt key is not correct. If the key is not correct, rclone can not decrypt even the names - and it discards this data. So if this happens to all files it is definitely the key that is the issue.
You should be able to verify this fairly easily by looking at the log using -vv and looking for tons of lines of "could not decrypt ...blah blah... invalid base32 something something"

I have some idea to why your key might be wrong.
When you input your original key or passphase in rclone config, it gets stored in obscured format in the rclone.conf file.

if you take that (already obscured) key and try to input it again into rclone config then it will effectively be run through obscuring process twice - and thus will be wrong when rclone decodes it to try and use it.

So either

  • Use your ORIGINAL (unobscured) passkey via rclone config
  • Use whatever (doesn't matter) in the rclone config, and afterwards open rclone.conf file and copy/paste the crypt key from your original config file to the new one. That will work fine (you need both keys if you used a socalled "salt" ).

The two password lines are identical, as I copied from one file to another. T

I also paid attention to the case of the remotes, to make sure there was no difference. The only difference from your example is that root_folder_id, is blank, and that should not be an issue, unless I am misunderstanding something.

Any other thoughts?

The strange part is the exact same thing worked for another user, and I even gave info on how to do it! Irony at it's best!


OK, found issue. Difference is very small, but enough to mess everything up. I think it might have to do with shares from more than one account, but this works.. Modifying the above example:

type = drive
scope = drive
token = {"[REDACTED] - created by rclone config"}
root_folder_id = [REDACTED] - created by rclone config

type = crypt
remote = Gdrive:Original-cypted-directory-name
filename_encryption = standard
directory_name_encryption = true
password = [REDACTED] - created by rclone config
password2 = [REDACTED] - created by rclone config

It shows all the files in the uncrypted mode, but will error if it finds uncrypted ones, and will not continue.

So, this works the way I want it. This is different from @TheJM's issue, as he used the directories.

Thanks @thestigma for the help!

Aaah, lol I see now.

You have made it harder for yourself then it needs to be :wink:
usually you have an unencrypted folder - that contains all of your encrypted files.
like for example Gdrive:/Crypt
That way it is still easy to reference. If you have to use the encrypted name then that becomes pretty clunky :slight_smile: (but it will work just fine)

I should probably have included this in my example, sorry :slight_smile:

and I recommend you keep encrypted and unencrypted files separate.
rclone should just ending up ignoring any non-encrypted files when viewing them through a crypt remote - but it will produce a lot of errors while doing so (but that shouldn't break anything either i think). Still - much preferable to keep it separate.

OK, I understand.


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