Ignore Pattern: no (neither on nodeA nor on nodeB)
Folder Versioning: no
Folder Type: send & receive
The issue:
I have two windows nodes and one synced folder
Content is moved to that folder on nodeA.
It is synced to nodeB without problems.
I manually delete a folder on nodeA.
On nodeB all files within that folder and its subfolders are deleted, but not the folders itself. < Thats the problem
The error-message
on nodeB reads:
Line1: folderX “directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally”
Line2: folderX\subfolder1\ “access denied”
Line3: folderX\subfolder2\ “access denied”
I guess the Line1 error is caused by Line2 and 3.
If I open CMD on nodeB and try rd folderX > access denied.
If I go into folderX and try rd subfolder1 > access denied.
Strange thing is - in explorer the user can DEL the folders without any problems.
Why can the same user (not an admin) not delete the folder via CMD?
PS. Forum formating question: Is there a way to make a return without adding an empty line or bullet points?
Not sure what the exact culprit may be in your case, but Windows throws “access denied” errors also when you’ve got too long paths, illegal characters somewhere in the path, etc. Can you provide a more concrete example of the path, where you’re seeing this?
Otherwise, please specify in details how you’ve installed and set Syncthing up.
I’ve watched the video. Because the problem doesn’t affect newly created folders and only happens when you try to delete pre-existing folders that have been copied from somewhere else, my guess would be that this must have something to do with Windows permissions preventing Syncthing from deleting them.
You may want to check what’s going on under the Security tab in properties of the pre-existing folders, and then compare it with what it looks like for the newly created folders.
I can not find any difference between the permissions of the two folders.
Here is an other video showing the content of the security tab of the relevant folders.
You wrote that no ignore would be set up. It could perhaps make sense to set this up if it is a matter of deleting “stubborn” files as well, if this prevents the deletion of folders, e.g. a few sample entries:
Under Windows the desktop.ini in my case was often a reason why folders could not be deleted completely. So if after deletion maybe some files over, this files could be the reason for your problem.
The problem affects empty folders, so I don’t think ignore patterns are really relevant in this situation .
I’m personally lost of ideas at this point. I can only suggest to test this in a different Windows system (and preferably a clean installation) and then see whether the issue persists there too.
If files in the folder structure cannot be deleted, the root folder cannot be deleted either. Then all affected subfolders or possibly also only the root folder remain and can possibly also not be deleted manually or only after a restart of the system or like that etc. I think this is a known effect from the Windows everyday life, which caused at least with me in connection with Syncthing initially repeatedly for trouble.
Since I have installed the shown Ignore pattern in all folders, I have no more problems in my environment.
From time to time I also encounter that “can not delete” problem during working with the Windows Explorer. So I tested sync with the suggested ignore pattern, but the problem still persists.
To make sure, that there is no permission problem, I used “takeown” in CMD to double check, that the current user has full access to the folders. But with no success.
C:\Users\User\Test2\1>takeown.exe /F 3
ERFOLGREICH: Die Datei (oder der Ordner) "C:\Users\User\Test2\1\3" gehört jetzt dem Benutzer "IX2\User".
C:\Users\User\Test2\1>takeown.exe /F 33
ERFOLGREICH: Die Datei (oder der Ordner) "C:\Users\User\Test2\1\33" gehört jetzt dem Benutzer "IX2\User".
C:\Users\User\Test2\1>takeown.exe /F 2
ERFOLGREICH: Die Datei (oder der Ordner) "C:\Users\User\Test2\1\2" gehört jetzt dem Benutzer "IX2\User".
C:\Users\User\Test2\1>rd 3
Zugriff verweigert
Some files/folders still had the “read only” attribute. Even though, I removed it from all files by unchecking the “read only” checkbox at the synced folders root level and confirmed “Apply changes to this folder, subfolders and files”. You may notice, that the checkbox in a folders (not files!) properties is always “half checked”. No matter what you do.
Solution: the CMD command attrib can remove the “read only” attribut. Here is the command, that cleaned over 1k files and folders from their unholy “R” attribute…
> attrib <path to folder>\* /s /d -r
PS. To get a list of all files, folders and their real attributes, the only way I know is to go for attrib <path to folder>\* /s /d . Redirect it (>c:\result.txt) into a txt, to have a file with all data, that can be imported into Exel for example to check and filter the results.
PSS. I accidentally overwrote the original post, so here it is again.
Actually this is only a workaround. Because in the future you may accidentally move folders that have this unholy attribut set into your synced folders.
Since no one checks all folders he works with via CMD/attrib this “no access” error might occur at any time.
.
.