And suddenly, file access became denied...

Hi!

I have been using Syncthing on 3 Windows machines (2x 10, 1x Server 2019) since October without any problem. Since the 1.7.0 upgrade, the first-level subfolders (relative to the share) return the “access denied” error on every machine. I fixed files and folders ownerships with the Windows Repairs from tweaking.com but the error still occurs. I can’t figure out what I should do. Has anyone any idea?

Many thanks in advance.

Syncthing doesn’t manage permissions/ownership, other than read only bit, so I am not sure how much we can help. You should make sure the user it’s running as has the right permissions in the whole directory tree recursively, and it should also be the only thing that creates the files in that directory, as I am not sure how permission inheritance works in windows.

Syncthing is running as the current logged on user. In the three cases, shared folders are users profiles. Ownerships, permissions and other attributes have never been changed. (I just tried a fix when access became denied.) So, running user matches files owner. I uninstalled then reinstalled Synctrayzor but it was useless. I see nothing wrong. It should work but it does not.

I guess see if moving to an older version fixes it, but I highly doubt it.

The fact that ownership and permissions have never been changed, doesn’t mean they are correct now, so I suggest you double check, also verify that the user is able to modify those files not via syncthing. I’ve seen hundreds of times Windows lock me out of access to my files that suddenly requires a restart.

Does it say exactly which operation is denied? As in the full error message in the logs.

Sorry, what I told at first about “first-level subfolders” was wrong. I just noticed that listed directories giving an access denied are junctions! I guess that I just have to put them in the exclusions list…

Scanner (folder WSAdmin, item “AppData\Local\Application Data”): scan: open \?\C:\Users\Administrator\AppData\Local\Application Data: Access is denied. The same for: AppData\Local\History, AppData\Local\Microsoft\Windows\INetCache\Content.IE5, AppData\Local\Microsoft\Windows\Temporary Internet Files, AppData\Local\Temporary Internet Files, Application Data, Cookies, Documents\My Music, Documents\My Pictures, Documents\My Videos, Local Settings, My Documents, NetHood, PrintHood, Recent, SendTo, Start Menu, Templates.

Log taken from Server 2019. The two others logs on W10 machines are quite the sames, with more or less entries.

I seem to remember something about there being junctions here which would previously not have been followed at all.

You might need to add them to ignores to retain the same behavior.

There are plenty of replies, have researched or tried what was suggested? There are also plenty of other threads on this topic I suggest you find via search.

You’re right. I asked too quickly. In my case, this is essentially a matter of ST now reporting that it doesn’t follow junctions.