S3Drive - Problem with sync post 1.14

Today I went to check my backups and find the app created some encrypted dirs(that is not using the encryption key that I set and also not in plain text) and in the sync page they all report no folders found. All my drives are E2E encrypted and files created/synced in the past can be accessed just fine, even drag and drop works fine, just sync is problematic. The only error in log is just saying no folder with the same md5 value is found, and I check back all the versions, all versions before 1.14.0 works just fine. My feeling is that sync in the new version is somehow using a different encryption key than the other functions? (edited)

1:58 PM

Tried re-adding all the storage and credentials, also doesn't help

JourinT

Today I went to check my backups and find the app created some encrypted dirs(that is not using the encryption key that I set and also not in plain text) and in the sync page they all report no folders found. All my drives are E2E encrypted and files created/synced in the past can be accessed just fine, even drag and drop works fine, just sync is problematic. The only error in log is just saying no folder with the same md5 value is found, and I check back all the versions, all versions before 1.14.0 works just fine. My feeling is that sync in the new version is somehow using a different encryption key than the other functions? (edited)

Hi, Is that mobile, desktop? What's your platform? Does the issue apply to built-in storage that we provide (listed as Ultimate) or the other one (Is that S3 or Rclone?).

and find the app created some encrypted dirs(that is not using the encryption key that I set and also not in plain text)

When you go to the "Profile Settings" and use "Show encryption key", does it show the encryption key? Please make a copy of it, before you restore it with your original one. Can you try checking if by any chance it is not not a base64 string? E.g. if it shows as: QWxhZGRpbjpvcGVuIHNlc2FtZQ== then the command on Linux would be

echo QWxhZGRpbjpvcGVuIHNlc2FtZQ== | base64 --decode

=

All my drives are E2E encrypted and files created/synced in the past can be accessed just fine,

In that case the encryption key must be set correctly, otherwise you wouldn't be able to decrypt the contents.

all versions before 1.14.0 works just fine

Are you saying that if you downgrade S3Drive, then the issue doesn't happen?

My feeling is that sync in the new version is somehow using a different encryption key than the other functions?

In [1.14.0] - 2025-07-02 release we've allowed user to set up crypt for Rclone backends, but we haven't changed anything related to existing encryption, be it default settings or encryption mechanism

even drag and drop works fine, just sync is problematic.

If you can't list folder in the Sync section that you otherwise see in the S3Drive listing then the typical root cause is enabling/disabling filename encryption at some point. S3Drive listing will display both directories (regardless if encrypted). Sync won't list entries where filepath can't be decrypted according to the settings. In other words, once you enable filename encryption, existing unencrypted filepaths won't be visible and handled by Sync. Same applies the other way round. Have you perhaps tried to disable/enable filename encryption recently? (edited)

3:00 PM

I hope we can get to the root cause of the issue. Please make sure to backup your existing encryption key in the app before proceeding, just to make sure that you can recover any files that were encrypted using that seemingly incorrect key.

Tom

Hi, Is that mobile, desktop? What's your platform? Does the issue apply to built-in storage that we provide (listed as Ultimate) or the other one (Is that S3 or Rclone?).

and find the app created some encrypted dirs(that is not using the encryption key that I set and also not in plain text)

When you go to the "Profile Settings" and use "Show encryption key", does it show the encryption key? Please make a copy of it, before you restore it with your original one. Can you try checking if by any chance it is not not a base64 string? E.g. if it shows as: QWxhZGRpbjpvcGVuIHNlc2FtZQ== then the command on Linux would be

echo QWxhZGRpbjpvcGVuIHNlc2FtZQ== | base64 --decode

=

All my drives are E2E encrypted and files created/synced in the past can be accessed just fine,

In that case the encryption key must be set correctly, otherwise you wouldn't be able to decrypt the contents.

all versions before 1.14.0 works just fine

Are you saying that if you downgrade S3Drive, then the issue doesn't happen?

My feeling is that sync in the new version is somehow using a different encryption key than the other functions?

In [1.14.0] - 2025-07-02 release we've allowed user to set up crypt for Rclone backends, but we haven't changed anything related to existing encryption, be it default settings or encryption mechanism

even drag and drop works fine, just sync is problematic.

If you can't list folder in the Sync section that you otherwise see in the S3Drive listing then the typical root cause is enabling/disabling filename encryption at some point. S3Drive listing will display both directories (regardless if encrypted). Sync won't list entries where filepath can't be decrypted according to the settings. In other words, once you enable filename encryption, existing unencrypted filepaths won't be visible and handled by Sync. Same applies the other way round. Have you perhaps tried to disable/enable filename encryption recently? (edited)

Is that mobile, desktop What's your platform?

I am on Mac os

Does the issue apply buit-in storage that we provide (listed as Ultimate) or the other one (Is that S3 or Rclone?).

One is provided by you, one is my cloudflare R2 storage configured as a S3 endpoint, they all suffer from this issue.

When you go to the "Profile Settings" and use "Show encryption key", does it show the encryption key?

It shows the key. And I can confirm it is not in base64, because my key is in word-word-word-word-word-word! format, and it is what it shows there

Are you saying that you downgrade S3Drive, then the issue doesn't happen?

Yes, I just use the dmg and overwrite newer installs. 1.13.0 and 1.12.9 all works fine without changing any configuration after replacement.

Have you perhaps tried to disable/enable filename encryption recently?

I did reconfigured everything after this report https://discord.com/channels/1069654792902815845/1386642710009614369 but I believe I enabled path encryption immediately after reconfiguration. Also now if I start fresh and readd my cloudflare R2 with my encryption key, it still have this problem of unable to list (edited)

Ok thanks for your feedback and sorry for the issue that you experience. We'll try to reproduce this issue on macOS specifically and see if we can find the root cause. Regardless, I will get back to you either with more troubleshooting details or a solution. Thanks!

1

Tom

Ok thanks for your feedback and sorry for the issue that you experience. We'll try to reproduce this issue on macOS specifically and see if we can find the root cause. Regardless, I will get back to you either with more troubleshooting details or a solution. Thanks!

Thank you as well❤️

JourinT

Thank you as well❤️

We've managed to locate the problem and release a 1.14.3 hotfix. Please update and let us know if this has resolved your issue. Once you update the app and rerun sync it should "just work", no action needed, except if there is any existing folder created with an obfuscated name you might want to clean it up. Don't clean it up before you make sure your new sync run succeeds, just in case you need to recover some files backed/synced to this obfuscated location (it is actually possible, but outside this comment scope). Thanks for the heads up.

Tom

We've managed to locate the problem and release a 1.14.3 hotfix. Please update and let us know if this has resolved your issue. Once you update the app and rerun sync it should "just work", no action needed, except if there is any existing folder created with an obfuscated name you might want to clean it up. Don't clean it up before you make sure your new sync run succeeds, just in case you need to recover some files backed/synced to this obfuscated location (it is actually possible, but outside this comment scope). Thanks for the heads up.

Can confirm it is fixed, thanks a lot for your help!