Syncthing "read-only" Windows folder(s) to / through Linux servers

Support
1

Hi, I have troubles to sync AND version files from customized (“read-only”) windows folders.

What do I have:

  • a station/client under Windows 10 - SyncTrayzor 1.1.22 - Syncthing 0.14.51

  • a server: Debian 9 - Syncthing 0.14.18-dfsg1

  • and a test folder - on Windows - with its content:

    D:\LetMeTry (this one is customized, so “read-only”, but it does not seem to change anything)

    • desktop.ini
    • SampleProject (this one is customized, so “read-only”)
      • desktop.ini
      • readme.txt
    • SampleProject - Copy (this one is “normal”)
      • readme.txt

The folder “LetMeTry” is synced from the station Windows 10 (no change in setting, so no versioning) to the Debian server where Simple versioning is set.

Any change done on Windows “LetMeTry\SampleProject - Copy\readme.txt” is synced and versionned as expected on the server.

Any change done on Windows “LetMeTry\SampleProject\readme.txt” provokes

  • on the client Windows the blue information “Syncing (99%, 14B)” which stays forever,
  • on the server the red “Out of Sync” message, nothing synced or versionned.syncthing
  • a click on the failed item on the server gives the “permission denied” information.syncthing2
  • There is a “.syncthing.readme.txt.tmp” file in the right folder but the “readme.txt” is still the old one, both are writable.

The only way out is to root delete “readme.txt” on the server.

I expected to be able to modify any file from any folder and sync these modifications without manual intervention. So what am I doing wrong? Is there any test or information I should look for?

Thanks

1 Like
2

What is the “right” folder and what is “both” in this case?

3

Can you reproduce the problem with a new directory, i.e. on windows, create directory “foo”, do whatever it takes to make it “customized/read-only” and wait for sync to linux. Then check whether the write bits on the permission of the directory on linux are missing. I am asking, because permissions shouldn’t be set on directories when pulling, only the setgid, setuid and sticky bits.

4

right folder: The “LetMeTry\SampleProject” folder on the server

both: “.syncthing.readme.txt.tmp” and “readme.txt” files

5

Just did it:

syncthing3
syncthing3692×317 96.8 KB

The first command on the server is once created on Windows and synced. The second one is once customized on Windows and synced.

The “testWithSimon” folder of course :slight_smile:

6

I had a more thorough look at the relevant code and don’t see how this can happen. You could run with STTRACE=fs on the linux side and look for executed chmod statements on the dir in question.

7

Thanks for your help!

Sadly I’m far from being an expert under Linux. I succeeded to run twice every step of the previous test with another user in console mode but I cannot see anything “interesting” in the log… which i probably didn’t do correctly :frowning:

Am I correct with running STTRACE=fs syncthing -logfile tests.log??

8

Yeah or just redirecting/tee’ing to a file and then uploading the log file here.

9

I re-tried this morning and cannot see anything interesting in the log, but let’s see: tests.log (7.3 KB)

Log on the Debian server while

  • creating on Windows the normal folder,
  • updating a txt file inside,
  • then customizing that same folder
  • and finally trying to update the same txt file.
10

This is without the filesystem debugging enabled, so not very useful.

11

That’s what I thought :frowning: Would you mind giving me a hand on how to enable it?

I ran STTRACE=fs syncthing -logfile tests.log for this one.

12

That should work, or you can enable from the log section in web before you try to reproduce.

13

Well it does not

Debian Syncthing v0.14.18 does not have “Logs” item in the web menu!

14

omg… How utterly blind I am - after reading the Win10 Syncthing version I totally skipped the one on debian. Unfortunately I don’t have time to debug such an old version, please update and try to reproduce again (options with apt are debian testing or the repo on apt.syncthing.net).

15

Didn’t realize it was that far behind too! And I understand you don’t want to spend time on this one.

I’ll try to update and check again tomorrow… to close this thread I hope!

16

It’s late but I had to try :slight_smile:

Just an old apt.conf parameter (APT::Default-Release “stretch”) which kept an old version.

Now the v0.14.51 is running everywhere, and of course the problem I described does not exist anymore! Everything is running fine!

I’m guessing you can "tag’ this thread as SOLVED! And thank you!

17

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