"Error reported while accesing file" & "Illegal characters in path"


I have Duplicati installed on a Windows 7 machine and set to copy from a network share (SMB/CIFS) to Nextcloud via WebDAV (I have other machines copying to the same server working flawlessly). All is working good except for three folders, I get “Error reported while accesing file” for this folders and the supposed cause is “Illegal characters on path” but the path doesn’t have spaces nor strange characters (accent marks, symbols… anything). The strange thing is that Duplicati is able to copy the subfolders IN the folders that fail.


I get the error on \\\FOLDER1\ (the content of FOLDER1 is not copied either, only it’s subfolders) but Duplicati is able to copy \\\FOLDER1\FOLDER2 and all it’s contents.

I hope someone can shed some light, thanks in advance!

Are all machines using the same version of Duplicati and backing up the same SMB share?

My guess is there’s a file (might be hidden) in the FOLDER1 that Duplicati chokes on so the moves on to the next think it can handle.

I’d suggest comparing what you can restore from that folder with the actual contents - that may highlight what file(s) are being skipped.

Oh, and can you post the actual error/warning message from the Duplicati logs?

Hi John,

Actually SMB is the source not the destination, destination is a Nextcloud server via WebDAV. Yes, all machines are using the same version and backing up to the same Nextcloud server.

I searched for hidden files and there aren’t any. And I looked to what can I restore before writing the post, what I am able to restore are the contents of FOLDER2, FOLDER1 looks like only contains FOLDER2 and no single file on it (and there are files).

Here’s the actual message:

2018-12-12 15:04:50 +01 - [Warning-Duplicati.Library.Main.Operation.FilterHandler-FileAccessError]: Error reported while accessing file: \\work\FOLDER1
System.ArgumentException: Illegal characters in path.
in System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
in System.IO.Path.IsPathRooted(String path)
in System.IO.Path.CombineNoChecks(String path1, String path2)
in System.IO.StringResultHandler.CreateObject(SearchData searchData, WIN32_FIND_DATA& findData)
in System.IO.FileSystemEnumerableIterator1.MoveNext() in System.Collections.Generic.List1…ctor(IEnumerable`1 collection)
in System.IO.Directory.GetFiles(String path)
in Duplicati.Library.Snapshots.NoSnapshotWindows.ListFiles(String folder)
in Duplicati.Library.Utility.Utility.<EnumerateFileSystemEntries>d__23.MoveNext()

Any hint? Thanks!

I wonder if you have control characters? They wouldn’t display. Is the remote source anything Linux-based?

Nope, not a single control character on the paths. Yes, it is a Synology NAS.

Were you able to see that in Windows somehow? I couldn’t think of a nice way, which is another reason I was hoping there was Linux around (even with BusyBox commands, but I think some Synology systems do better).

If you have solved the above, you could try a –log-file with –log-file-log-level=Verbose (if Duplicati is current), which would show all the pathnames as Duplicati considers them. Maybe that will show something interesting. Some of the processing (I’m not sure of details) is asynchronous, but with luck the warning will be inserted in some reasonable place, and you can see the sequence of files/folder processed before it (and maybe after).

If you’re directly on the NAS, you could try some commands below. I’ll give both single-letter and long options.

ls --escape
ls -b

A plain ls command can be piped to
cat --show-tabs --show-nonprinting
cat -T -v
and then you could pipe to `fgrep ‘^’ to look for a caret, which I’d think would otherwise be very rarely used.

Although on the surface, this seems to be an issue in the top folder, you could inspect everything if you do
ls -R
ls --recursive

egrep has character classes, if you want to try those

The less viewer might also be handy. I’m not sure what on Windows works easily. Hex editors are awkward.

Windows Subsystem for Linux or Cygwin might be too much to ask, but can inspect NAS files from Windows.

I’ve seen varied information on illegal characters, but control characters are sure, and some of <>|":*?\/
Linux is much more tolerant of characters, which is maybe how it’s possible to get in illegal character issues, especially if direct Linux access is allowed. If the only way into the NAS is Windows, then I’m more puzzled…

Duplicati isn’t directly testing characters, or triggering that error. It’s simply passing along what .NET gave it. Possibly we can figure out what it’s seeing, either through our direct inspection, or in the log of what it sees.

I’m getting similar errors like:

* 2021-01-22 02:00:01 -05 - [Warning-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-PathProcessingError]: Failed to process path: /my-path/T�lechargements/

On my debian install, local backup to remote. This is from a shared Samba directory.