Started a new sync task this morning and as it got started, I saw this:
Even though it says it couldn’t create the folder (which was already in place), it is copying files and appears to be working. However the error message is still in place.
Any thoughts?
Can you post a screenshot of the Web GUI with the folder in question unfolded? What is the actual path on the disk?
There you go (the server with the error message):
This is the other server:
The error message is about file watching not working (which is visible in the screenshot, i.e. “Failed to setup, retrying”). The folder path itself looks fine, so it’s difficult to say what the culprit may be 
.
The only difference I can see between this task and any of my other tasks is that the drive letter is lowercase whereas in all the other tasks it’s uppercase. I can’t see where that has anything to do with it.
This task has a long way to go to be “complete”. I’ll wait until it’s done to see if syncing is actually taking place or not and report back.
Can you check what exactly is the path set to in config.xml?
You can find the file in %LOCALAPPDATA%\Syncthing (basically copy and paste this into the address bar in Windows Explorer). You should be looking for something like <folder id="default" label="Default Folder" path="/Users/jb/Sync/".
Here you go:
<folder id="njuel-yvyva" label="Project Files" path="d:\Shares\PData" type="sendreceive" rescanIntervalS="3600" fsWatcherEnabled="true" fsWatcherDelayS="10" fsWatcherTimeoutS="0" ignorePerms="true" autoNormalize="true">
That’s from the system with the error message. Do you need the other server’s line as well?
The other side doesn’t matter. The path in the config looks fine though, so it’s still very unclear why the error about it being incorrect, and only for the file watcher.
The initial copy finished overnight. I am left with 2 files in error:
I now believe there is some kind of permissions problem on the problematic server. Why? Because I can’t use the Syncthing WebGui to create an STIGNORE file:
Even though, the Syncthing Service Account is part of the “Users” group on the server:
And the “Users” have full control of the folder and subfolder being synced:
Also, automatic syncing is only working in one direction: From the Lexington Server to the Hazard Server (the one with the error). I have to manually start a rescan on the Hazard server to get anything sent back the other way.
I’d prefer not to have to start from scratch (2.19TB takes a while to move across a WAN connection), but if I must, I will. I just can’t fathom what is going on with this particular folder when 5 other folders are working properly between the same two servers, with the same configuration.
I’m completely at a loss.
OK, so this is kind of mind-blowing for me. The path on the problematic server that Syncthing is working on, “D:\Shares\PData”, is mounted to a volume in a NAS.
When I set permissions on the “PData” folder with Windows Explorer and forced it to overwrite the permissions on every file and folder below it, only the current folder was being changed. A file six subfolders below retained the default permissions given to it when the file was created.
When I set up the Syncthing folder, I didn’t know there was another set of permissions. Permissions set at the volume level. These are the permissions that were used when creating the initial set of folders and subsequently the files - with “Users” only having Read and Execute permissions.
After right-clicking on the PData folder, choosing properties, and then clicking indicated by the green rectangles:
I was able to set the proper missions at this level. When applying those permissions, Windows properly sets the permissions I expected to see on every file and folder in the volume.
Why it’s like this, I have no clue. (Someone please enlighten me.)
Now the only real problem I have is the original error:
As syncing IS now working in both directions:
(I’ve also been able to create the .stignore file through the web GUI.)
I’m kind of wondering if the error is related to anything that Syncthing creates in the folder when it first begins and if there is a way to force that to be done now.
I don’t think so. Syncthing does create a folder marker (by default called .stfolder) but if it had failed to so, the folder wouldn’t even be syncing right now. File watching doesn’t create anything visible inside the folder.
Further update: Realtime syncing (ie, syncing triggered by file watching) is not working. The watcher on the Hazard Server is still not enabled and the only time anything gets sent back to the Lexington Server is when the 1-hour or manual rescan is triggered.
I don’t know what else to do at this point. Google is not helping.
Pulled this from the logs a few seconds ago:
2024-08-09 13:11:24 Error while trying to start filesystem watcher for folder "Project Files" (njuel-yvyva), trying again in 1h4m0s: CreateFile /D:\Shares\PData\: The filename, directory name, or volume label syntax is incorrect.
That’s basically the error displayed. That path with the slash in front of it makes no sense. Am I looking at restarting/rebuilding this sync folder job?
Generally speaking, don’t run Syncthing against a network mount, run it on the device where the disks are. Unless it’s Synology I guess, because then it’s going to suck either way 
NAS… if only we’d started with that bit of crucial info. 
File watching relies on a feature in Windows, macOS, Linux and other supported OSes. With limited exceptions, a client OS doesn’t have direct visibility into remote filesystems – i.e. the server OS hosting the physical storge volume doesn’t send change notifications across the wire to the client OS.
So network file share mounts generally must rely on regular scans to detected changes. The error above will persist until “Watch for Changes” feature is disabled for that Syncthing folder.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
