macos uid/gid and fsevents

I have been a resilio sync user, but I suspect that resilio is either switching away from small fry such as myself and going more enterprise now or disappearing soon. they are no longer responsive support-wise, even for paid users. so I am planning to migrate to syncthing.

I have read many syncthing docs. may I ask some clarifying questions?

  1. I understand syncthing does not offer much uid/gid support on macos and linux. (I understand that free is free.)

if I understand it correctly, syncthing typically runs as non-root user, and all files it pulls down from elsewhere receive the process user’s uid and gid. correct?

my plan is to run syncthing as a systemd daemon, either on macos or linux. if I run syncthing as a setuid-root daemon, this would mean that all files would be uid root. (this may not be recommendable for security reasons.) correct?

  1. how does syncthing detect file changes on linux and on macos? does it hook into the OS? (for macos, this presumably means fsevents.) polling or traversing would be painful.

  2. resilio sync had no command line utility that I could give a local file and a remote host to, and learn why the sync did not fail…from peer problems to permission problems to whatever. instead, one needed to email resilio the logs and they would set a human detective on learning the cause and emailing back. this seemed very wasteful. with open source, at least there is a good chance that this may yet be written. or does something like this already exist?


Syncthing doesn’t sync ownership, correct. There is a special option to set the ownership according to the parent directory which may be useful depending on your use case. Changes can be detected by file system notifications, yes.

I don’t understand your last question.

thank you, jakob.

last question: every so often, resilio would not sync. so, the user had to track the cause. their website has not only a web page “” but a full crowded forum for troubleshooting plus a staff dedicated to sleuthing the logs for the cause.

frankly, this seemed like a waste in many cases, especially when the user already has root privileges on both. there should have been a command line utility

$ whynotsync /path/existing filethatshouldsync  host-where-it-did-not

such a program should then systematically check through possible causes. such as “is there a network connection?” (which may require placing a test file and waiting), “are the permissions sufficient?” etc.

There is nothing like that in syncthing and it seems like an invasive measure potentially opening up security gap. You have to check on the device where the issue is happening to know why its happening.

in principle, it can be written, though :-).

I would think that an automatic diagnosis could be done fairly safely by someone who is more competent than I. it could be a short script that would write 0-byte temp files, use ssh [requires login!], etc. it’s probably as safe as letting users poke around by hand. after all, the user already has access to the local space and expected the file to show up on the remote space, so presumably he/she had access there, too.

The automatic diagnostic is done by Syncthing, which displays in the GUI why a file couldn’t be synced. If something better could be written to draw smart conclusions based on the logs, this smartness could (and should) be built into syncthing directly.

By reading this forum and all the user-questions about “why does my sync not work (as expected) ?” I learned that in most (if not all) cases the “staff” (and the user providing logs…) found the reason very quickly (independed of the users understanding) and if there is a case, where syncthing could be improved, the “staff” makes preparations to improve syncthing, aka bug-reports and/or patches/fixes and expand the documentation.

This may seem like the resilio support (or crowded forum), but its better, because you don’t only get your problem(s) solved, you actually learn something (and not only about syncthing).

So by the time, you see the logs and know what the problem is and where you need to dig.

Btw: The automated diagnosis program sound interesting to me, so give it a try, I will surely test it. :slight_smile:

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