Something’s up with your permissions then. There are thousands of windows users who are running Syncthing unprivileged and have no problems, myself and the SyncTrayzor users included.
@hww Windows permission is a strange thing. Hard to understand and even harder to implement correctly if you ask me. wwweich is right. You should not run Syncthing as administrator. I hope someone will share their knowledge on how to make Syncthing work with other folders with difference permissions like network shares on windows.
@fpbard You’re right. I am not at all fond of running programs with elevated privileges as I can avoid it.
Earlier I suspected some kind of permission problem, see post #11 of this thread. I therefore opened up access to the local partition in question (the whole logical drive). I gave full access to everybody. Checking the effective permissions reveals that in fact letterly everybody logged in has full, unlimited access to that drive. But that didn’t help.
Who of the thousands of windows users @canton7 mentioned could point out which permissions one must use in order to get Syncthing running as a normal user?
Does everyone have access to all files within that drive? Remember that windows permissions aren’t necessarily inherited across folders.
@canton7 Yes they have. Everybody has full access to everything on this particular partition. I explicitly propagated those permissions to all subfolders and subitems.
But you’re right anyway. Running Syncthing as administrator is no solution at all, because this makes all directories and all files newly created or modified belong to root/root on the file server which in turn leads to bad permission problems on either side.
So running Syncthing as administrator makes it monitor my partition, but destroys permissions on the server. Running Syncthing as a normal user doesn’t notice mutations on my local drive.
What can I do about that?
What NAS are you using? For some NAS boxes there are Syncthing packages which can be installed directly onto the NAS.
I’m afraid I’m struggling in the same places as @AudriusButkevicius: your screenshots don’t add up. Sometimes there are 131 files on both sides, sometimes around 7. You’ve also corrected your statements over time. Additionally there are network drives involved, but I’m not sure entirely where.
Would you be able to put together a summary of all of your findings up to this point, including all of the evidence you’ve seen to indicate that syncthing isn’t functioning correctly, etc, all in one easy-to-read and easy-to-comprehend place? That would really help people like me who are coming to this thread late.
@hww, in order to faster find the problem, it’s recommended to provide just a minimum working setup. I think that neither @canton7 nor @AudriusButkevicius have noticed that you are sharing partition (or shared drive) I:\, which has 131 files, but you are actually doing tests in I:\tmp, that has only 7 files.
EDIT
To check if it is a common issue with permissions in Windows I’ve just tried:
- Device A: SyncTraizor 1.0.29 (Syncthing v0.12.1) running in a Win7-64 with an administrator account
<admin1>. The repo is inF:\repo. - Device B: Syncthing v0.12.1 running in a Win7-64 with an administator account
<admin2>. The repo is inD:\shared\repo. The Syncthing executable is inD:\Syncthing.
It’s working ok.
I created a user account with non-administrative privileges in Device B, <user>, and copied C:\Users\<admin2>\AppData\Local\Syncthing to C:\Users\<user>\AppData\Local\Syncthing.
I close the <admin2> session, entered as <user> and launched Syncthing. Everything is working as expected. I can create, modify or delete files in Device A and/or Device B, and changes are properly propagated.
However, a warning message is displayed, relating to the default repo:
2015-11-10 14:21:22: Stopping folder "default" - GetFileAttributesEx \\?\\C:\Users\<admin2>\Sync: Access denied
which maskes sense.
Quick answer: In folder shared by ST is 131 files (should be 132), 6/7 files is in subfolder (called tmp) of that shared folder. There are no network drives included in sharing, only when he looks from windows to that folder on NAS he uses samba share. But folder itself is shared by ST directly from NAS. “Shared” is only NTFS partition in laptop (more like alternately used by windows and kubuntu).
Thanks. Has he used the /rest/db/file endpoint to see what Syncthing thinks exists at the missing file’s path? Has he examined/posted the logs from both sides (particularly the puller’s side, as that will indicate puller issues)?
Is it preferable to share the configuration directory among different OSs in the same machine?
Not yet. Up until now this whole conversation is basically “what’s going on” with little “why” only after 25. post.
EDIT3: Actually this whole comment was stupid, because calmh was pointing out difficulty with 2 separate indexes and I didn’t understand what he meant.
I think calmh was (at the time he was writing that post) thinking that he hww shares his index between kubuntu and windows, but that is not the case. I also think that sharing index and config in this case would not help, because ST on windows would still have permission issues.
EDIT: If I would use such set up (dual boot) I would definitely (unless I encountered some issues) use of shared conf and index, because changing two conf files whenever I wanted to change some of ST settings would be annoying.
EDIT2: I didn’t realised conf file has paths using different folder separator (/ vs ) according to OS on which ST is used, so sharing conf file between windows and linux without parser of some kind isn’t possible. Sorry about confusion.
A shared index would be a recipe for disaster, I think. Syncthing would effectively see your entire set of files as disappearing at one path and re-appearing at another
According to a post (which I don’t find at the moment), the index has the file paths only relative to the “main folder path” in a neutral manner (/ vs. \).
So the index and the cert could/should be shared, while the config should not, as one of the systems would not be able to find the folder paths.
Aha, OK.
I think in index paths are saved relative to shared folder path, because when I shutdown ST, move shared folder and change path to it in config, start ST again everything works like nothing happened (I done this several times). Also in this case even paths to shared folders are same, because it is only one shared folder.
Yeah, that about sharing config file was stupid, I will edit that post.
@1138-4EB Thank you for pointing out the core of my problem. I’ve got the impression that my descriptions tend to contain too much words, so everyone looking at my question could have gone lost.
Eventually, I succeeded in solving the problem.
It wasn’t Windows that failed. It was myself with the setup of my file server. Its sole purpose is having it act as a Samba server. The file shares on that server are set up such that they can be accessed by everybody from everywhere within my intranet. Therefore, Samba assigns all files and folders to user ‘nobody’ and group ‘nogroup’.
On the other hand, Syncthing ran as root on the server, so all files and directories made up by ST belonged to ‘root/root’ which caused all of my troubles.
Yes, I learned than ST should not run as root, as @wweich first pointed out, not even on the file server. Therefore I made up a separate user ‘syncthing’ on my fileserver, sharing the UID of ‘nobody’. Starting ST under that account was the key to succes.
Now I’m enjoying a functioning setup of ST, meanwhile involving two desktop machines under Windows and the dual-booted laptop (Windows/Kubuntu) besides the Linux file server.
Thanks a lot to the developers of this fantastic tool, and to the helpful community. I’ll be staying tuned.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.