Since we use syncthing on our news production, we get a lot of “access denied” errors.
We sync multiple windows computers, the folder is always in the user folder base. We have one android device and one windws 7 VM on a synology NAS two that are syncing this folder. One computer is set to receive only, it’s the only one not synced on a user folder, in a folder with special permissions
Anytime we delete folders on the VM, we get “access denied” on those files on the other computers that can access the folders (they are empty folders and .lnk files). Then at one point the error dissapears and the folders are synced back on the VM.
We are trying to find if it’s a problem of one computer resyncing everyhting (corrupt database or smthging?) or a problem with the way we set ignores, with synced permissions or something else? All the computers seems to have admin privileges on those folders
Also, moved files are resynced on other computers in the source and target dir so we have duplicates and when people connect on the sharedfolder, it triggers modification on every file in the shared folder.
Also the issue for the access denied has already popped up a lot so a lot of solutions were tried, the user can delete the folder, syncthing is launched as admin and every user on the desktop has all rights possible to the undeletable folder.
(And when it happens we have a log that syncthing will try to resync the file in 1h04m but he does it every second until the folder is deleted or resynced by someone else)
Maybe if you post screenshots and copies of exact errors, ideally with screenshots of what the permissions etc for the files are, we can deduce something. As is I can’t say there’s much to go on other than
that there’s a lot of “special” going on here - Android, Synology, special permissions, somewhat outdated Windows, all of which are known to be a bit tricky.
I’d suggest simplifying your setup to something more homogenous, making sure that works, then adding complex components one at a time.
You can effectively remove the android device and synology of the equation, we have mainly Windows 10 instances, one Windows 7( that I doubt cause issues on this case but we can always migrate it to windows 10 if really necessary), and 2 MacOS.
The android one wasn’t here at the beginning and was removed, the issue is present. We don’t have syncthing on synology, we just have a Windows 7 on synology.
Here are the errors we get for the access denied part :
Run as admin should not be needed to delete folders that every user on the device can delete and so should not impact Syncthing to delete the folder. Several devices on the network have the same issue of not being able to delete a deleted folder on another device
Yes it is a different issue than the inability for Syncthing to delete the folder, I currently don’t have the feedback to know if today the issue was solved or not by the new release
It seems to me that several other users over the past years have had similar issues that are still open to this day.
I know that it is specific to Syncthing because Python scripts and users can delete the folder.
Also just in case we have on our .stignore : (?d)desktop.ini
There’s confusion about the specifics in the issue tracker. We have no problem deleting read-only folders on Windows, as far as I know, but indeed it’s impossible to delete folders with a custom icon, because the custom icon is entirely invisible and makes the folder read-only without it looking read-only. os.RemoveAll doesn’t defeat that, either.
(Also the Read-only attribute Windows does not mean that a folder is read-only because a folder is only a list of content so it would be non sense, it’s a legacy and used to know if os should look for a desktop.ini for the folder)
Not using RemoveAll is fully intentional, as we don’t want to do a recursive deletions. For some reason I don’t understand the patch that addressed the link issue only concerned RemoveAll, not Remove - I can’t find any rationale. We could in principle work around it by checking if there’s any content in the directory if we get a permission denied error on Remove, and if there’s not, use RemoveAll.