Indexing errors prevent full file backups on Windows clients

I recently tried to move my server’s backup data directory to another local drive, which was a much bigger mess than I’d expected. After moving the backed up data and restarting the server pointing to the new location, it kept getting hundreds or thousands of errors during file backups, so I re-installed the server (with 2.5.28), restored the original server keys, and eventually got the server and clients communicating normally again.

Now when it tries to do a file backup on the Windows clients, I get this type of error which ends the indexing process:

Errors 02/23/23 13:22 Cannot access path to backup: “\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy80\sers” Errorcode: 2 - The system cannot find the file specified.

File backups on my Linux clients are working perfectly, as are image backups on both types of systems.

In the default File Backup settings I have “\Users" set as the only default directory to back up, with exclusions for "\Temp*;\Games*;\OneDrive*”. These settings were working for months before re-installing the server software.

Big question is where is it getting the “\sers” on the end of the error path above from, and why isn’t it using the “\Users” that I specified? I’ve re-entered the default directory to backup in the settings several times with slightly different varriants but still get similar errors each time (the number after “…ShadowCopy” changes slightly sometimes).

Any thoughts or suggestions about how to fix this would be much appreciated!

Just noticed that any time I used a wild card character in the post above, it got edited so it sometimes drops the adjacent slash character - which I have no idea how to edit to fix. In any event, the file backup setting fields are more normal and should be correct, despite how they show up above. Don’t know how to escape the wild card character, so this web site won’t interpret them itself and change what was entered…

You can backslash the backslashes (See Test4 in the image below), or you can surround the text with backticks (see Test5 below). Note that the method in Test5 also results in a fixed width font being substituted, and a subtle background shading. Test6 uses “code” tags instead of backticks, and the result is the same as Test5.

The actual text I typed is on the left, the resulting preview is on the right. These are all common conventions used in various programming languages and web forums to control what you are trying to display. You run tests like I did below to find out which works on which different forum. Test4, Test5 and Test6 below show you what works here. Test9 not only ate the backslash, but it also added a few unexpected newlines.

Screenshot at 2023-02-23 21-27-40

p.s. - It is interesting to note that in Test6 (which works) we surrounded the word “code” with square brackets. In Test7 (which didn’t work), we surrounded it with angle brackets. But in both of these cases the forum software recognized square brackets and angle brackets as being something special (it did not print them in the preview pane).

But when we did the same thing with the work “pre” in Test8 and Test9, the forum software did not recognize the square brackets in Test8 as being anything special, and actually printed them in the preview pane. It would seem our particular forum software is inconsistent here.

I fixed it by changing the “Default Directories To Backup” setting to point to a specific disk on the Windows client system (“C:”) instead of using a wildcard at the front of the parameter. No idea why that worked since I thought I was successfully using a wildcard in the past…