syncing: finishing: pull: generic error

Support
1

Hi,

I have a “generic error” in my setup and all related forum posts have been unhelpful in my situation.

I have a 2-computer setup, computer A runs Ubuntu 20.04LTS while computer B runs Ubuntu 22.04LTS. Files on computer A will synchronize without fail to computer B but any file created on computer B refuses to synchronize to computer A, with this “generic error”.

I am not using encryption, the permissions on the files that sync and those that don’t are all the same. The log doesn’t show more than the “syncing: finishing: pull: generic error” message for the files that don’t sync.

Any idea as to what could cause this issue or at least where to look at?

Thank you for your help,

2

Looking at the code where this error may be produced, a debug-log line will be tossed prior to this error - each of them seem to indicate a quite specific issue.

I’d suggest turning on the debug-logging for ‘model’ and try to see what debug messages are being shown prior to this generic error. That would help in deducting where this issue originates from.

And/or (in case the log was already more extensive) copy the entire log message here.

3

I’ve turned on the ‘model’ logging as suggested. Most of the “generic errors” were not preceded by anything else but in some case, SyncThing was a bit more loquacious. Here’s an example with one of the troublesome files:

2023-11-05 19:43:11 sendreceive/SSD_DOCS@0xc0010fa400 need file Audio/Chinese/04 .mp3; copy 32, reused 0

2023-11-05 19:43:11 progress emitter: registering SSD_DOCS Audio/Chinese/04 .mp3

2023-11-05 19:43:11 weak hasher open /home/jean/Documents/Audio/Chinese/04 .mp3: no such file or directory

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 1

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=11 o=1441792 s=131072 h=39474d001c00795548617ddf68dcd57a2ba39dc219aa843e239a40724d3d743b wh=979f3e6 ft=false

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 2

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=12 o=1572864 s=131072 h=7a01cde4711a42907d137d19d7dc43821d4c6c02871269f38da8adcdce46bc15 wh=335179cd ft=false

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 3

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=13 o=1703936 s=131072 h=1a9d46f3e39c9744011edff400e7a8d2fcb300f166c278e817657b9bad73be31 wh=938c29ac ft=false

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 4

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=14 o=1835008 s=131072 h=d217dd8045ccb0e94afdb2f8ad5a4defd7eddeea391669fac59d36441f334a39 wh=8c92c059 ft=false

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 5

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=15 o=1966080 s=131072 h=9e02cf8494d661d612378009af83ac7dc9671773bb24c248186d6225eb8a0656 wh=c0abcefb ft=false

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 6

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 7

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=16 o=2097152 s=131072 h=153dfcbb98aa24f8bc2c4e7b390a181582bac903e3b436396ae9451fe8b3a0b9 wh=87f438ce ft=false

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=17 o=2228224 s=131072 h=59ff9bf2c6e1cbe023a5aba3b0a3f98446c52341735bf96e53fa9780d6a1d9f1 wh=42656303 ft=false

2023-11-05 19:43:11 sharedPullerState SSD_DOCS Audio/Chinese/04 .mp3 pullNeeded start → 8

2023-11-05 19:43:11 model@0xc000002000 REQ(out): L5ZLEHX (192.168.1.59:22000-192.168.1.18:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-2UAAUKBVRHM9E3MLT6TPH57EOS): “SSD_DOCS” / “Audio/Chinese/04 .mp3” b=18 o=2359296 s=131072 h=b9edd523e6e1920dcfe56757f429ca4aa2232cfeb45126c19793c59a254be817 wh=9fdf929b ft=false

4

You don’t need debug logging, you need logs from the other device where it’s pulling from: The specific error happens there, but isn’t sent over to the other device, that’s why you see a “generic” error there.

1 Like
5

Nothing is showing in the logs on the other device.

6

Right, so the combination of @er-pa’s and my recommendation is right: model debug logging on the device where the data is coming from should have info. I didn’t realize we only logged those at debug level - I don’t really understand the reasoning for that.

7

I should have specified: model debug logging is also activated on the sending machine.

8

And at the same time that you get the “generic error” on one device, you should get a message containing “REQ(in)” on the other device.

9

Sadly, no : this is the log on the sending machine, before and after the previously posted log on the receiving machine :slight_smile: 2023-11-02 17:12:06 … 2023-11-05 20:09:28 sendreceive/SSD_DOCS@0xc003b5e380 parent not missing xxxx.ods 2023-11-05 20:09:28 sendreceive/SSD_DOCS@0xc003b5e380 need file xxxx.ods; copy 4, reused 0 2023-11-05 20:09:28 progress emitter: registering SSD_DOCS xxxx.ods 2023-11-05 20:09:28 sharedPullerState SSD_DOCS xxxx.ods pullNeeded start → 1 2023-11-05 20:09:28 model@0xc000103380 REQ(out): QVCZYQ5-QPO2CS6-N742CGY-ZAXMRN7-3JE54HF-JCSDNOB-TV76SGQ-M

Nothing about the troublesome file.

10

You didn’t post the logs for REQ(in) from the other side.

11

Do I need to activate any other logging option besides “model”? Right now, REQ(in) is not showing on either log.

12

It’s just model.

If I had to guess, you have some untrusted devices/folders with passwords involved leading to this.

13

Could full-disk encryption (LUKS) cause the issue? I otherwise don’t have folders with passwords on any of the systems.

14

Its hard to say, we still haven’t seen the logs that explain the error.

You could capture both device logs with model debugging enabled.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.