Syncthing carries on making specific folder encrypted when I don't want it to be

First off, thanks for creating Syncthing, it’s an awesome product!

My setup is: I have folder A, and I have folder A1, which is a subfolder of A. I ignore A1 in A’s ignore patterns, so there’s no “double-sync” attempts.

This is an annoying, convoluted setup, but it’s because I want to include A1 on some of my devices, and don’t want to include it on others – and I need to preserve the directory structure. So I see no other way of doing this, given a device can only “not send” a file, it can’t choose to “not receive” one.

Relevant devices are X, Y, Z, where X and Z are trusted, and Y is untrusted.

My problem is: whenever I try and share folder A1 between X and Z, even though I’m not typing in an encryption password when I do so, it adds one on after I’ve shared the file. This leads to an error because both ends are encrypted, and neither are set to Receive Encrypted (they’re both Send & Receive). If I remove the encryption password on both ends, this leads to an error because both sides think the other wants to exchange encrypted data.

I have no clue why both remotes are expecting encrypted data?? The encryption password Syncthing carries on adding is the same one I use for Y, so I assume that’s got mixed in somehow? But I’ve checked my setup, and there should be no reason this is happening.

This happened with folder A before as well, but I somehow got rid of the problem by removing and adding the folders on both ends multiple times, and frantically clearing the encryption passwords. This has not got rid of it here though.

Error message on device X: Failure checking encryption consistency with device Z for folder “FOLDER” (DATE): remote expects to exchange encrypted data, but is configured for plain data

Error message on device Y: Failure checking encryption consistency with device X for folder “FOLDER” (DATE): different encryption passwords used (I’m especially baffled by that message, because I used the same encryption password when sharing from both X and Z.)

Device Z doesn’t currently have an error message, but I think it had the same one as X before (I think the error message just shows on the one you try to share from, whereas the other one just silently Disconnects).

Both X and Z when I check the logs, have mutual connections ‘closed by remote: handling cluster-config: remote expects to exchange encrypted data, but is configured for plain data’. Y closes connections too. When I remove the offending folder, everything works again.

Actually, I think I just experienced the bug. On device X, I’d previously shared A1 just with Z (to try and isolate the problem), and had removed the encryption password Syncthing had added in. However, when I then shared A1 with Y, with the encryption password, it then added that same encryption password to Z. Even though I’d left the field for Z clear.

Long post, but I hope I’ve given enough detail here that this issue actually gets sorted.

Your local passwordmanager, the browser or one of its addons is meddling with the UI. Syncthing doesn’t set a password per default.

1 Like

Welcome here @thxforcreatingst .

Can you please provide screenshots from X and Z? In particular from “Edit Folder” for one of the affected folders, tabs “General”, “Sharing” and “Advanced”.

It’d be strange if it was though, because I have autofill on my password manager turned off. And the password is only added in after sharing the folder, not on the actual Sharing tab.

X:

Z:

(I temporarily removed A1 from X because of the trouble it was causing, but when I had it on, A showed the same warning as on Z about being a parent directory.)

I got the error ‘Sorry, new users can only put 5 embedded media items in a post.’ So here is the final screenshot:

Hmm… I don’t see anything wrong. In particular, the share on X with Z does not have a password. The same in the other direction. Good!

Can you also screenshot device Y?

I’m also getting errors on Y: ‘Failure checking encryption consistency with device X for folder “A” (rr4vp-rv3ux): remote has encrypted data and encrypts that data for us - this is impossible’.

I suspect if I delete all the folder contents and try re-syncing it, the errors will go away, but it’s a lot of data so would be very inconvenient.

1 Like

I agree with your suspicion. First you might want to try by removing all folders in SyncThing on all three machines, but NOT in the filesystem, and then re-share. And remember that a backup is your best friend in case something goes wrong.

I have done this, and tried to re-share from X to Z, but an encryption password is still added, even though I don’t set it.

And I know that if I unset the Untrusted checkbox it will come up with all the encryption mismatch errors again, because I’ve tried this before.

Just to see what would happen, I set a different encryption password, shared, then deleted and tried re-sharing again without an encryption password. Once again, it re-set the password I use for Y.

The only other thing I can think of is it’s some sort of error due to trying to sync an iCloud folder. But in theory this shouldn’t be an issue, because all the files are locally downloaded on my device. And…

Just checked with a non-iCloud folder, and it still happens. Tried sharing to a different device I have, and it didn’t. So it happens for any folder, but only when sharing from X to Z.

Does it happen from Z to X? I tested this, and on Z’s end, it didn’t. But, as soon as I accepted the folder on X, it added a password, and then I get a ‘Failure checking encryption consistency’ error.

So anything X touches gets encrypted when Z is involved, apparently.

Is there anything at all in Syncthing where one specific device could auto-set encryption password with another specific device?

If not, I think this might be a bug.

I am still a bit stumped.

I think the time has come for you to reproduce this on a new folder and preferably on a new set of devices while creating a numbered list of steps to reproduce.

1 Like

With a different browser…

1 Like

I tried with a Chromium-based rather than Gecko-based browser, and it still happens. Interestingly, the browser does notice that a new password has been set, because it offers to save it.

I think now, I’ll try removing all devices, and see if the problem persists when I add them again.