How about narrowing down the scope of this issue, e.g. by seeing if a single large file backup can get it? Probably that’s primarily data reads as opposed to other things that may go bad such as attribute reads.
Even more likely to be a relatively basic reading test would be Duplicati.CommandLine.BackendTool.exe, simply doing a put
of an SMB source file somewhere, even to a local destination folder to be even easier. Target URL (especially for file) is pretty easy, but if you want you can copy from Export as Command-line.
It would also be useful to try to correlate (or not) time of Duplicati access errors with kernel syslog errors. Yours seem to be uptime-seconds. I don’t know if syslog is configurable, but dmesg -T
is human-friendly.
Deeper still is strace, where one can see that mono runs a lot of signals, interrupting system calls which possibly cause later issues. Typically slow ones such as file reads should expect to get an EINTR errno (whether or not they do in mono is a question), whereas “fast” system calls should not return an EINTR, which by the way is a 4, which might be what the -4 in the message is telling us. I think it’s using errno…