You shared one folder between two devices, both trusted, and set the password on both devices, right? That should work, but isn’t useful: That will only add overhead for encryption and decryption on both sides, while the data never stays encrypted anywhere. You only need to set the password when sharing with an untrusted device.
If you check the logs on the other device, the actual error reason should be logged. The protocol only transfers the generic error messages you see here, which aren’t particularly enlightening.
I want to sync data between different clients and a rented VPS server where syncthing is also installed. The clients should connect to the syncthing server as only that IP is always the same and known. I don’t want any relaying and discovery services to be used. The data should be encrypted on the VPS server as I don’t trust the owner and as I don’t have physical access to it. The data must not be encrypted on client side necessarily. As of now I used cryptomator but there I had to manually do the syncing.
Is my scenario possible with syncthing? And how do I need to configure it?
Yes, that’s exactly the intended scenario. Lets say A and B are two of your trusted clients, and U is the untrusted VPS. Keep sharing between A and B as usual (folder type send-receive, no password set for each other). When sharing the folder with U on A/B, you do set the password (when selecting U to share with). Then when you get the folder invitation on U, the folder type will automatically be set to receive-encrypted. If you manually add the folder on U, you need to make sure the folder type is receive-encrypted.
The new encryption feature has nothing to do with discovery. You can sync through the untrusted device, without A and B being connected. To get a direct connection between A and B they still need to discover each other through the usual mechanism.
It’s always ideal if all clients are on the same version, but they don’t need to be in general (all v1.x are compatible, though in practice you will run into problems with old clients, just because of bugs having been fixed since then).
For the new untrusted feature you cannot run an old client, because the feature is only ready to be used since v1.16.0.
ok thanks I think I understood…
So as A and B clients are not always online and have changing IPs it does not make sense to connect them directly. So I will use the untrusted VPS to connect to both clients and the data is stored encrypted there in receive only. The clients know the pw and can edit the data. So this should work right? Thanks!!!
This is really awesome if that would work
@imsodin: thanks I got it working now!
I have another question…does it make sense to enable versioning on untrusted VPS? If I want to restore it complains about unexpected files. This is ok because folder is receive encrypted only…
So should I better disable it and only enable versioning on the clients which also store versioned files unencrypted?
Also what I noticed: When deleting a file from a trusted client, the encrypted folder structure on the untrusted VPS stays but with no files…How get these folders deleted?
Edit: Just noted that they are deleted perhaps because of automatic rescan?
I thought we disabled versioning restoring when the folder is receive-encrypted - apparently not.
Versioning might still be useful, as you can manually decrypt the versioned files. It’s a niche thing though I’d say, as it won’t be that easy to see what is what and do the appropriate steps to restore.
I remember adding such a cleanup condition somewhere - probably in the scan indeed. We could also check parent dirs when deleting a file during syncing on receive-encrypted devices. Well anyway, cosmetic issues - right?