I use KeePassXC on my linux laptop and KeePassDX on my Android phone. It doesn’t matter KeePassXC open or closed, the files cannot be synced for unknown reason.
There should also be failed items shown in the folder pane - click on them and you’ll get the concrete errors. If not, please post screenshots of the entire UI.
There’s definitely no general issue with syncing keepass dbs, a lot of Syncthing users including myself do it (for me it’s the exact same pair of apps that I use).
Thanks for providing all those infos!
That points at an issue on ThinkPad when it gets a request for data from Poco. When you rescan on ThinkPad, are there any errors? If not, could you enable model debug logging (Actions > Logs) on ThinkPad, and then pause and resume the passwords folder on poco (to trigger a sync attempt). Then provide those logs please.
I tried to rescan on ThinkPad and Poco, also I restarted Syncthing and devices but got the same error.
logs from ThinkPad
2022-02-01 12:26:09 Enabled debug data for "model"
2022-02-01 12:26:22 Handling ClusterConfig from E3DFY2Y
2022-02-01 12:26:22 Removing index handler for device E3DFY2Y and folder smzgj-lohtc
2022-02-01 12:26:22 Exiting index handler for smzgj-lohtc to E3DFY2Y-*******-*******-*******-*******-*******-*******-******* at 192.168.1.14:22000-192.168.1.4:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256: context canceled
2022-02-01 12:26:22 Removed index handler for device E3DFY2Y and folder smzgj-lohtc
2022-02-01 12:26:22 Handling ClusterConfig from E3DFY2Y
2022-02-01 12:26:22 Device E3DFY2Y folder "Passwords" (smzgj-lohtc) is delta index compatible (mlv=13)
2022-02-01 12:26:22 Starting index handler for smzgj-lohtc to E3DFY2Y-*******-*******-*******-*******-*******-*******-******* at 192.168.1.14:22000-192.168.1.4:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 (slv=13)
The relevant bits come later when you pause and resume the folder on the other device. I am looking for lines containing REQ(in) (and surrounding ones).
I press pause/resume many times on Poco and there are no any lines in ThinkPad logs contains REQ(in) I see lines contains REQ(out) in the Poco device logs
Logs from Poco
2022-02-01 14:04:30 model@0x40002bed00 REQ(out): 2FP2LHE-*******-*******-*******-*******-*******-*******-*******: "smzgj-lohtc" / "Passwords.kdbx" b=2 o=262144 s=131072 h=e8e131bbb133e82d5213c93abb250dc8ac2d806891683309 wh=e2316ecc ft=false
2022-02-01 14:04:30 request: smzgj-lohtc Passwords.kdbx 131072 131072 returned error: generic error
2022-02-01 14:04:30 request: smzgj-lohtc Passwords.kdbx 0 131072 returned error: generic error
2022-02-01 14:04:30 sendreceive/smzgj-lohtc@0x40000a4380 closing Passwords.kdbx
2022-02-01 14:04:30 sendreceive/smzgj-lohtc@0x40000a4380 new error for Passwords.kdbx: pull: generic error
2022-02-01 14:04:30 progress emitter: deregistering smzgj-lohtc Passwords.kdbx
2022-02-01 14:04:30 request: smzgj-lohtc Passwords.kdbx 524288 131072 returned error: generic error
2022-02-01 14:04:30 request: smzgj-lohtc Passwords.kdbx 655360 98853 returned error: generic error
2022-02-01 14:04:30 request: smzgj-lohtc Passwords.kdbx 393216 131072 returned error: generic error
2022-02-01 14:04:30 request: smzgj-lohtc Passwords.kdbx 262144 131072 returned error: generic error
2022-02-01 14:04:30 sendreceive/smzgj-lohtc@0x40000a4380 changed 1 on try 1
2022-02-01 14:04:30 sendreceive/smzgj-lohtc@0x40000a4380 copiers: 2 pullerPendingKiB: 32768
2022-02-01 14:04:30 sendreceive/smzgj-lohtc@0x40000a4380 parent not missing Passwords.kdbx
2022-02-01 14:04:30 sendreceive/smzgj-lohtc@0x40000a4380 need file Passwords.kdbx; copy 6, reused 0
2022-02-01 14:04:30 progress emitter: registering smzgj-lohtc Passwords.kdbx
Usually it’s best to just post full debug logs from the affected devices. The developers will then be able to find the lines they need. Sometimes people are afraid of doing so because of sensitive information and such, but you’ve only two files here, so … 
.
but I don’t see there lines with REQ(IN). That’s why I don’t know which logs should I share.
What I usually do is to shut Syncthing down, delete any existing log files, then re-launch it with debugging enabled (which is model in your case). Next reproduce the issue, shut Syncthing down again, and upload the whole log file that was created in the meantime.
For the record, do not copy the logs from the GUI, because they’re only partial. The best way to save everything is to start Syncthing with -logfile=<path-to-a-file>.
Also, because Android is involved, if I remember correctly, the log file there should be saved automatically by the app to /sdcard/Android/data/com.nutomic.syncthingandroid.
Hmm, that’s peculiar. That means the request is going to the galaxy and not the thinkpad, which might be due to a newer change to the files there. And as there’s no sharing between galaxy and thinkpad, only poco has the problems. Can you check the galaxy for errors and/or connect it to the thinkpad.
I did the following steps:
- Shutdown Syncthing on ThinkPad and Poco
- Delete log files
- Run Syncthing on ThinkPad with flag -logfile=Syncthing.log
- Run Syncthing on Poco
- Add model flag to logs on both thinkpad and poco
- Make some changes in the KeePassXC and save the database
- Pause folder sync on both thinkpad and poco
- Resume sync on both thinkpad and poco
- Shutdown Syncthing on both devices
log files attached syncthing_ThinkPad.log (8.7 KB) syncthing_Poco.log (83.9 KB)
I deleted Galaxy from all devices. The error is the same.
Are the logs above from before or after removing galaxy?
I have no idea what’s going on: Literally every place where this “generic error” is used is accompanied by a debug log line which contains either Request or REQ - neither is present in those logs. The protocol itself doesn’t use these errors. Nevertheless, a next step would be also enabling protocol to see what’s happening there.
I tried to share passwords with Galaxy device and got this error notification
The same was with Poco too, may be this is the reason of problems with sharing. what do you think?
I found the reason (((( that was my fail (( I set password for folder as untrusted device
1 Like
Yes that’s it, you shouldn’t do that. You don’t have any folders set as receive-encrypted, so there’s no point.
2 Likes