Folder has failing file transfers

For several days I’ve been seeing a ‘folder has failing file transfers’ message in syncthing/synctrayzor. Here are the relevant log entries:

2020-09-04 08:36:49 Completed initial scan of sendreceive folder apps_a2010 2020-09-04 08:36:49 Puller (folder apps_a2010, item “trustex\docs\20200610 cbc g sample data”): delete dir: remove \?\C:\mso\apps_a2010\trustex\docs\20200610 cbc g sample data: Access is denied. 2020-09-04 08:36:49 apps_a2010: Failed to sync 1 items

There is nothing special about this folder, other than I have been editing some files in it recently (xls mostly). I’ve tried some improvised fixes but nothing has helped - for example, I turned off the machine that reports the sync error, and removed that entire folder from the pc it syncs to, and restarted the error reporting pc. It resync’d fine, as far as I can tell, but the error remains. My admin login is the owner of the folder on both pcs (windows 2012 r2 domain).

What can I do about this Access is denied error? I wonder why it reports the folder as giving the error, when clearly it does have access to the folder? It was able to resync the folder’s contents…

I even moved the reported problem folder from both pcs (moved out of sync area) and the same folder is still reported by syncthing with the ‘access is denied’ error. How can that make sense? The folder isn’t present on either side at this point.

This is a simple operating system access denied error. Syncthing doesn’t have permissions to delete that directory.

But my tests…I remove the folder from both pcs that have the folder. THE FOLDER NO LONGER EXISTS. Syncthing still reports that it can’t sync that folder? It is not there to be sync’d or deleted.

My windows account is admin level. It is the owner of the folder on both sides. The same user account owns all of the other peer folders and they do sync.

It doesn’t make any sense.

Sure, it reports the last error, if the folder is not there anymore, perhaps next pull cycle it will clear. If it has been in this state for a while, the pull cycle has probably gone into large pauses between tries because of repeated failures.

You can pause/unpause the folder and see if that helps. If it still complains about the same folder, perhaps it can’t even read/list the parent directory where the directory is supposed to be located.

We’re just giving you an error we got from the operating system, this is not an error message we’ve invented, as for why that error happens, we can’t answer that, we’re not the ones behind the operating system.

I had told it to rescan and it didn’t fix the issue.

I fixed it by removing the parent folder from syncthing. After a short time, the request showed up from the other pc that it wanted to share that folder; I accepted, and the sync’d fine. I added the ‘problem’ folder back into the parent folder that was now sync’ing ok, and it also sync’d fine.

Obviously you know 1000x more about syncthing than I do, but it looks like a syncthing error to me.

A bit more on this. I’ve found that the issue arises only when I rename a folder. Renaming the folder has this effect: on the other pc, the new folder is created and content it moved to it. However the now empty original folder remains. On the pc that has the empty folder, it is reported as “access denied”, and will apparently remain there forever. I can delete that empty folder manually and then a rescan reduces the count of “access denied” failures by one. This is a new issue.

Does your folders have customisations, like custom icon and what not?

No these are plain folders, often with just one or two text files inside them.

No idea, they must somehow be magical if go fails to delete them.

What is “go”? They’re not magical, they’re bare bones folders created manually by myself, with very sparse content. Something that might be true, have not tested, is that on one machine one of the contained text files might be open in notepad++ when the folder is renamed on the other pc. I have not tested this, just could be a scenario.

Is SyncTrayzor (and thus Syncthing) actually running with administrative rights?

I am asking because 3rd party software in Windows seems to need them in order to create folders and files in the root of your system drive (typically C:\).

I would expect so - my account, the only active user, and the creator of all of these folders and files, is a domain admin. When I manually delete one of these leftover empty folders, it’s simple, just like deleting any other empty folder would be. And these folders are several levels removed from the root (c:, d: etc)

Manual operations using Windows Explorer or the command line are possible even without administrative rights. But if you try to do the same using something like a 3rd party explorer replacement, you will get a Run as Administrator prompt. For me, this looks like a permission issue between Windows and SyncTrayzor/Syncthing.

Does the same problem happens when the folders are located in Documents or on the Desktop?

I don’t sync anything in those windows profile based folders, so I don’t know. I use windows explorer, yes. But as I am the domain admin, and the creator of all of these files and folders, it is a sure thing that the active account has perms to bump off any of these folders. These two pcs (one is a vm) have been using syncthing for about 2 years, with the same manner of use by myself, same user account, and this issue has not arisen before the last few weeks. Now it’s a regular thing when renaming a folder. At least I know how to clear the issue now.

Well, with the information provided it is kind of impossible to tell why the problem has arose like that recently. However, testing locating them in one of the user profile based folders is just a good way to check whether the issue is location/permission related or not.

If you do believe that the issue is caused by Syncthing (or possibly emerged after one of the recent Syncthing updates), then posting fuller logs may possibly shed more light on it.

The single log entry posted in the first post is enough to tell you that it’s a permission error coming from the OS. Why, I can’t tell you, but syncthing definately gets access denied when trying to delete whatever it’s trying to delete.

There isn’t any way for me to know if the issue is with syncthing or with synctrayzor or windows. I’m not sure how I can post the logs without exposing the names of the orgs that I work with (folder and file names), and by munging the info in the logs I’d be reducing the utility of such. It doesn’t sound like I’m going to get resolution on this issue but at least now I have found the common cause (folder rename) and an easy fix. Thanks for everyone’s input on this. Syncthing and synctrayzor are both quite amazing at what they do, I can easily live with a minor issue like this.

You can also try running just syncthing, without synctrayzor and see if that helps. Or explicitly running syncthing with administrator priviledges.