Access Denied when we delete folders + Resync problems

Hey all 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)

We are using a mesh setup.

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 :

They are empty folders, here is the permission of one of them :


This is purely down to the operating system permissions.

This is nothing todo with syncthing as far as I can see. The same user deleting those files via explorer would have the same error.

As said earlier, the user can delete the folder without an issue and as show above in the screenshot, every possible user has every rights possible on the folder so it’s definitely not an os issue

How is Syncthing run though? Which user is it run as?

We ran it as the current user which is Synosc, the admin account. We also ran the executable “As admin”

And also nobody adressed the issue that renamed folder on one device is not recognized as renamed so we end up with the other devices syncing the old folder and we end up with duplicates :confused:

I’ve got a feeling that running “as Admin” may be the problem here.

This looks like a completely different issue. Have you updated to the newest version (i.e. v1.22.1)? There was a bug in v1.22.0 that could potentially cause such problems.

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 :confused:

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

Is it possible that os.Remove is used instead of os.RemoveAll on the windows folder ?

As stated in this issue on the Go repository, removeAll will delete potential read-only folders but remove won’t.

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.

Ok so Syncthing still has a bug that prevents him from deleting a Windows folder because I don’t have a custom icon on it and only Syncthing can’t delete it.

@calmh read the thread you will see that what I sent you fixes your issue with folders with icons if you use removeAll instead of Remove :+1:

(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)

I looked up in the code, almost every reference to the functions RemoveAll from lib/fs/ are in tests files and every references to Remove are in the actual code, it doesn’t make sense.

Just look at :

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.

I agree that It doesn’t make sense to patch only removeAll that’s why the issue is still open but It’s the reality of Golang remove on windows for now. But in the case of

		if err := f.mtimefs.Remove(dirsToDelete[len(dirsToDelete)-1-i]); err != nil && delErr == nil {

Where we delete folders, is there a reason to not use removeAll, as if we deleted the folder elsewhere, it means we want also to remove its contents.

We already check before in the code if the folder is not empty to prevent its deletion.

Line in folder_sendrecv.go

Also the line should be after all the variable checks in the code or else it will try to delete even a non-empty folder.

I opened a pull request on go repo with a patch for os.Remove, I guess it will fix that when it will be up

1 Like

Is it not easier for you to remove funky icons from the folders to get them to work?

I don’t think we’ll switch to RemoveAll, as its prone to race-conditions, i.e., we think the directory is empty and about to delete it, but the user drops in a file, which RemoveAll would nuke.

Right, more reasonable would be to add the same as the patch for removeall, i.e. try to remove after adding 200 permissions.