Issues with ecrypted target folders: Unexpected items, inconsistent state. and conflicts

Hi all,

I’m having trouble getting encrypted folders to work; specifically, I’m seeing “unexpected items” errors and “.sync-conflict” files, even though (IIUC) syncthing shouldn’t be creating such files in an ecrypted remote. I hope this is the right place to ask.

The issue happens relatively consistently in normal use, making encrypted remotes unusable in my setup, but unfortunately I haven’t found a consistent repro. Instead, I have a recipe that consistently leads to sync-conflict files being created, which hopefully is a useful start:

  • Create a folder on the source machine. Share it with the destination machine, with a password.

  • Accept the share on the destination machine. At this point, the global state will say “0” on the destination machine, and synchronization will not start until syncthing is restarted. I suspect this is the source of the issue, but I’m not sure how to debug it: Screenshot from 2022-11-11 10-54-45

    … this is despite the source having non-empty state: Screenshot from 2022-11-11 10-55-07

  • Restart syncthing (systemctl restart syncthing) and wait for synchronization to complete: Screenshot from 2022-11-11 10-55-33

  • Remove the folder, stop syncthing, and delete (rm -r) the test/.stfolder.removed-20221111-105603/ folder on the destination’s file system

  • Restart syncthing, accept the folder again and put it in the same path as before. Screenshot from 2022-11-11 10-58-20

    … notice how the “global state” is wrong again

  • Restart syncthing again, and syncthing will create conflict files: Screenshot from 2022-11-11 10-58-49

    … notice the 4 in local state. Indeed, on the destination’s file system, we have:

    # ls -R test
    6.syncthing-enc  Q.syncthing-enc
    NK2FKOD9J4GQKEN7F4S5LKG1G  NK2FKOD9J4GQKEN7F4S5LKG1G.sync-conflict-20221111-105829-
    S97KM983CLH7R2QP9PVTPFMA0  S97KM983CLH7R2QP9PVTPFMA0.sync-conflict-20221111-105829-

I realize that the recipe above is stressing syncthing, what with removing and re-adding folders. But it also leads to an easy reproduction of the problem I observe (but can’t reliably reproduce) on my normal folders: conflict files and unexpected items.

Is this a bug, and if so how can I diagnose it? It would seem that the “global state 0” might be the root of the issue, but how do I diagnose that?

Thanks a lot!

  • Syncthing version: syncthing v1.22.1 “Fermium Flea” (go1.19.2 linux-arm64) 2022-11-02 06:27:53 UTC [noupgrade]

  • OS: Debian GNU/Linux 11 (bullseye) (Armbian)

Does it look similar to Does the broken state persist even after restarting Syncthing?

It looks similar, yes. But note that i"m experiencing problems even when synchronizing to empty / newly created folders.

The problem does persist after restarting as well as pausing / restarting; in fact, the recipe I posted includes a few restarts already ^^

While I only have a reproducible recipe for the sync-conflict files above, in my non-artifical attempts a reproducing the bug I’ve seen all sorts of other issues:

In the last case syncthing was spinning the hard drive a few seconds or so while attempting a sync, but nothing progressed.

This is all in a two-peers setting on LAN (so no missing peers or device).

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