Unable to use encrypted endpoit

Help and Support
1

I had some directories synced to a s3 storage in encrypted form, I remember I moved from base32 to base64 due to filename size limit, my hhd failed and now I'm trying to copy files from the s3-crypt storage but getting this error:
rclone --crypt-filename-encoding=base64 copy -P idrive_main: main

ERROR : ccc/bookmarks: Failed to copy: failed to authenticate decrypted block - bad password?

When I checked encryted files, I think there is mix of base32 and base64 filenames, not sure why:
image

Can I copy files via using corresponding encoding for each file name?

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

rclone v1.67.0
- os/version: ubuntu 24.04 (64 bit)
- os/kernel: 6.8.0-35-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.22.4
- go/linking: static
- go/tags: noneH

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

iDrive e2 s3

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

rclone --crypt-filename-encoding=base64 copy -P idrive_main: main

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[idrive]
type = s3
provider = IDrive
access_key_id = XXX
secret_access_key = XXX
endpoint = t2g1.fra3.idrivee2-56.com

[idrive_main]
type = crypt
remote = idrive:main
password = XXX
2

At least on you picture everything looks like base64

I think above is self-explanatory. Are you sure your password in crypt remote is correct? Is it obfuscated?

1 Like
3

If password would be wrong how it would print files names and some file contents correctly?

4

It can happen I think when you used custom salt before. password2 in the config file.

In general there are only two options here really. Either there is problem with password (wrong one, missing seed etc.) or source data is corrupted.

1 Like
5

When I sync, how can I make sure that there is no corruption on the remote (s3) side? so when I run sync it would calc and compare checksums or a hash?

6

I use iDrive S3 myself with crypt and never had slightest issue. IMO corruption even theoretically possible is rather unlikely.

I think you did something when you "I remember I moved from base32 to base64 due to filename size limit".

If you are paranoid you can also run rclone cryptcheck after every sync.

And good practice is to try to run restore from time to time to check if it works as intended. Because really what you need is successful restore not successful backup:)

1 Like
7

I have data copy on the another HDD, so next time will check remote as well :))
thx

8

Good you have proper backup strategy. One backup only is always risky - especially remote one.

What I would do is to run first some smallish amount of data sync verified with full restore. To validate that all setup is working.

1 Like
9

Did you migrate to base64 encoding properly? By just starting to use --crypt-filename-encoding=base64 Doesn't automatically rename existing files to the new encoding (they will be left as base32 encoding) and rclone can't decode these as they are not base64 decodeable.

10

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