Hello all. I’m trying to migrate to Syncthing and I’m testing my first shared folder now. I already connected 2 devices with each other. I set up a shared folder on one device and entered an encryption password in the ‘Sharing’ tab. Now I can’t seem to figure out where on the receiving device I should be entering this password for the data to be decrypted and readable. For now, it just appears as 3 folders.
I think it’s in exactly the same place, assuming you setup the folder type correctly.
Thank you, I managed to find it. First, I had to click ‘Advanced’ and then change the folder type from ‘Receive Encrypted’ to ‘Send & Receive’. Then under ‘Sharing’ I was able to enter a password.
However… It has now caused another issue. Syncthing refuses to sync. (I’m using SyncTrayzor on Windows 10) I’m seeing this output in the Syncthing Console:
[TVPZE] 18:42:32 INFO: Folder "Test" (test) isn't making sync progress - retrying in 1m8s.
[TVPZE] 18:43:53 INFO: Puller (folder "Test" (test), item "test.txt"): syncing: pull: generic error
[TVPZE] 18:43:53 INFO: "Test" (test): Failed to sync 1 items
[TVPZE] 18:43:53 INFO: Folder "Test" (test) isn't making sync progress - retrying in 2m14s.
This keeps going on like this every time it retries. Has anyone encountered this before? Any ideas?
EDIT: I should note that without using encryption, everything works fine. So I’m guessing it’s related to the encryption setting rather than a network issue.
If you are decrypting the data on both sides, whats the point of using encryption?
The plan is to run Syncthing on a another machine (off-site) that I can’t always have physical access to and to which other will have physical access as well. This device won’t always be online, so it’s necessary for me that this configuration I’m testing now works as well.
That doesn’t work, there’s a reason you can’t change it in the normal folder edit modal. You need to remove the folder in Syncthing, either remove the encrypted files on disk or decrypt them with syncthing cli, and then finally re-add it as send-receive if you want to switch from encrypte to not encrypted.
Do I understand correctly then, encrypted sharing only works in a T1 <-> U1 <-> T2 configuration? (Untrusted (Encrypted) Devices — Syncthing v1 documentation) Meaning if U1 were to be offline then sharing is halted since T1 <-> T2 won’t work with the encrypted setting? (As I seem to be experiencing now)
No that’s wrong: There’s no problem with T1 sharing to T2, both being send-receive.
Alright. So this T1 sharing with T2 (encrypted) is what’s not working for me.
[TVPZE] 20:42:38 INFO: Puller (folder "Test" (test), item "test.txt"): syncing: pull: generic error
[TVPZE] 20:42:38 INFO: "Test" (test): Failed to sync 1 items
[TVPZE] 20:42:38 INFO: Folder "Test" (test) isn't making sync progress - retrying in 1m1s.
[TVPZE] 20:43:39 INFO: Puller (folder "Test" (test), item "test.txt"): syncing: pull: generic error
[TVPZE] 20:43:39 INFO: "Test" (test): Failed to sync 1 items
[TVPZE] 20:43:39 INFO: Folder "Test" (test) isn't making sync progress - retrying in 1m1s.
I’ve configured both as send-receive as per the screenshot: https://imgur.com/a/b0w6bQQ
I can’t figure out why it’s not working.
Did you check the logs on the other side?
Yes, these are the last logs in the console of the other machine. (Let’s call it T1)
[WVXW2] 20:20:20 INFO: Ready to synchronize "Test" (test) (sendreceive)
[WVXW2] 20:20:20 INFO: Restarted folder "Test" (test) (sendreceive)
[WVXW2] 20:20:20 INFO: Completed initial scan of sendreceive folder "Test" (test)
[WVXW2] 20:20:36 INFO: Device XXXXXXXX folder "Test" (test) has a new index ID (0xXXXXXXXXXXXXXX)
T1 doesn’t seem to be producing more logs every time T2 gets ‘syncing: pull: generic error’
This is not a cause for your errors, but I still want to mention it: There’s no need to set the encryption password on both T1 and T2 for the respective other. That just adds overhead with no benefit. Once you add U1, you set the password on T1 and T2 for U1 only (not T2 and T1).
If any of the folders is still the same one where you changed folder type from receive-encrypted to send-receive → you need to remove and readd that folder in Syncthing (db is likely messed up). If that’s not the case, then on the T2 please enable model and protocol debug logging and send what it is logging when you see the generic errors on the other device.
I went ahead and built this setup locally, from scratch, by running 3 separate Syncthing instances on my computer. I realize now that I did not conceptually understand how this setup worked but I do now. So thank you for sticking with me!
For continuity, and in case it may be of use to someone who finds this thread at some point, here is what I did: When setting up T1 <-> U1 <-> T2, the encryption password is used on both T1 and T2 but not U1. T1 and T2 are in ‘send & receive’ mode (in my case at least) and U1 is in ‘receive only’ mode. If U1 is offline though, T1 and T2 cannot sync. For that, I connected T1 <-> T2. For this no password is needed since they are both trusted systems. (This is the part where my reasoning went all wrong in my past testing)
As per your comment “This is not a cause for your errors”, I think it is though. If I set a password on T1 for sharing to T2 and on T2 for sharing to T1, which I understand now is unnecessary, it really just doesn’t work. I think passwords only work when the node receiving new data is in ‘receiving only’ mode.
If that’s not the intended behavior, perhaps it’s a bug. 
In any case, thanks again!
1 Like
I really appreciate this thread as I have not properly explored the “T1 <-> U1 <-> T2” topology for Syncthing.
My most common use-case is what I would call a "point-to-point" cloud, but what I gather you are working on is basically setting up a self-hosted cloud server, in that there is an intermediary node where all files remain encrypted for later retreval by devices other than that which uploaded the files to the encrypted (“untrusted”) node. This merits further exploration. 
You use password only if the other node is “receive encrypted”.
Having passwords for each other when both are send-receive is pointless, but should work (I tested it at some point).
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.