File Watcher not working on Mac OS

Hi there,
I switched from Resilio Sync to Syncthing recently, but I got an issue with the file watcher. Whenever I tried to activate it, the watcher does not work and I need to sync by hand the files.

I have no log whatsoever on something failing, even activating and deactivating watcher. I tried to launch in the terminal the binary (Coming from Homebrew) with the STRACE option like :

$ export STTRACE=watchaggregator,scanner

The only relevant log I get would be :

[JZZFI] 2020/01/22 18:58:23.180158 aggregator.go:307: DEBUG: aggregator/"$$$$$" (gyscs-zq4ej): No tracked events, waiting for new event.
[JZZFI] 2020/01/22 18:58:23.180182 aggregator.go:307: DEBUG: aggregator/"$$$$$" (pfqgk-dtxkv): No tracked events, waiting for new event

No logs of failing but no logs of file watcher starting or something …

For info my configuration :

  • Mac OS 10.15.2
  • Syncthing 1.3.3

Those logs just show that the file watcher is waiting for events. So if you change something, nothing happens (you need to wait some 10s of seconds)? If yes, more info about your system and full logs might give a clue, but it doesn’t really sound like it. And as it is working for other s on macos, this will be hard to debug (if there is anything to debug) - just to prevent setting hopes too high.

If I add, remove or change anything in the folder nothing is synced even if I wait like 10min.
I would try to reinstall completely Syncthing but I already ditched the one which was coming from Hombrew and replace it by the one downloaded directly from the website. Is there any

I know watching folder is based on notify on Linux and via lsof it’s possible to see which application is watching which directory. Is there any same stuff from Mac OS ? To check if synching is actually watching something ?

You can find the full log here :

2020-01-22 19:16:09 My ID: JZZFIBR-ZBBKUKT-JLSJJXE-UF5X3AK-QC4TZK5-GUHKNT2-UIU7GUZ-FROC6Q3
2020-01-22 19:16:09 Single thread SHA256 performance is 165 MB/s using minio/sha256-simd (150 MB/s using crypto/sha256).
2020-01-22 19:16:10 Hashing performance is 132.10 MB/s
2020-01-22 19:16:10 Overall send rate is unlimited, receive rate is unlimited
2020-01-22 19:16:10 Ready to synchronize "Sync Pictures" (gyscs-zq4ej) (sendonly)
2020-01-22 19:16:10 Ready to synchronize "Cloud Drive" (pfqgk-dtxkv) (sendreceive)
2020-01-22 19:16:10 TCP listener ([::]:22000) starting
2020-01-22 19:16:10 QUIC listener ([::]:22000) starting
2020-01-22 19:16:10 GUI and API listening on 127.0.0.1:8384
2020-01-22 19:16:10 Access the GUI via the following URL: http://127.0.0.1:8384/
2020-01-22 19:16:10 ...
2020-01-22 19:16:10 My name is "Mango"
2020-01-22 19:16:10 Device 44WRIAK-X276BWC-7FOR7FE-ZZVMVKB-YQSBYDD-H3GSOQ7-7OVDMKT-EONBHAY is "Lemon" at [tcp://192.168.1.10]
2020-01-22 19:16:10 Established secure connection to 44WRIAK-X276BWC-7FOR7FE-ZZVMVKB-YQSBYDD-H3GSOQ7-7OVDMKT-EONBHAY at 192.168.1.6:64648-192.168.1.10:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
2020-01-22 19:16:10 Device 44WRIAK-X276BWC-7FOR7FE-ZZVMVKB-YQSBYDD-H3GSOQ7-7OVDMKT-EONBHAY client is "syncthing v1.3.3" named "Lemon" at 192.168.1.6:64648-192.168.1.10:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
2020-01-22 19:16:11 Completed initial scan of sendreceive folder "Cloud Drive" (pfqgk-dtxkv)
2020-01-22 19:16:29 Completed initial scan of sendonly folder "Sync Pictures" (gyscs-zq4ej)
2020-01-22 23:15:25 Connection to 44WRIAK-X276BWC-7FOR7FE-ZZVMVKB-YQSBYDD-H3GSOQ7-7OVDMKT-EONBHAY at 192.168.1.6:64648-192.168.1.10:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: writing message: write tcp 192.168.1.6:64648->192.168.1.10:22000: write: can't assign requested address
2020-01-22 23:15:49 Established secure connection to 44WRIAK-X276BWC-7FOR7FE-ZZVMVKB-YQSBYDD-H3GSOQ7-7OVDMKT-EONBHAY at 10.0.1.11:55175-192.168.1.10:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
2020-01-22 23:15:49 Device 44WRIAK-X276BWC-7FOR7FE-ZZVMVKB-YQSBYDD-H3GSOQ7-7OVDMKT-EONBHAY client is "syncthing v1.3.3" named "Lemon" at 10.0.1.11:55175-192.168.1.10:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256

One thing I tested :

  • If I use the default Sync folder in /Users/me/Sync the watch is apparently working
  • If the folder is in /Users/me/Documents/Drive it’s not working
  • If the folder is in /Users/me/Picture/Sync Library it’s also not working

I tried this now and for me it still works to get events from at least ~/Documents. I was thinking there may be some magic since those folders are now under extra protection, and I even have my ~/Documents floating in the iCloud, but I see events as expected for file edits in there. 10.15.2 here as well.

Ok I thought I found the issue !
First, I went to gatekeeper’s stuff in the System Preferences and enable full disk access for Synching (Maybe a more precise folder permission can be done but it was for testing purposes). And wanted to share the “~/Documents/Sync Pictures” folder (I know I added complexity with spaces). So I restarted the synching app, and added the share next to the default one.
In the UI, the auto-complete stuff filled the path with:

/Users/Me/Documents/Sync Pictures

Which sounds good because synching was able to analyse all folders and files, so far so good ! But file watcher didn’t worked well. So even checking in the Console app, parsing all logs, nothing. And When I checked the default folder, the path was:

/Users/me/Sync

Modifying /Users/Me/Documents/Sync Pictures/ to /Users/me/Documents/Sync Pictures/ and now watcher is working !

So I don’t know if it’s an European stuff to reference user folder with me and Me, like when you can use Pictures folders event if you have your Mac in Italian or French.
Is it at least possible to deactivate syntax check on the Path field ? It would avoid most of the issues I think.

OsX filesystem is not case sensitive, so I think the case difference is a red herring and not actually the cause

Syncthing is though and didn’t we have some code to reject events from outside the folder root, where the folder root might be case sensitive? I’m too lazy (let’s call it busy) to check so I might be talking crap.

We indeed do, and we do it case sensitively on all OSes except windows. However that does not happen silently, but trigger a watch error and warning, so that should be visible in the UI if it happens.

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