I installed on CentOS 7 Duplicati 2 (last canary - 220.127.116.11_canary_2019-11-05). After a few time I see that progress stopped and only after about 10-15 minutes I saw how new files appeared.
But after about 30-60 minutes I see error: “One or more errors occurred. (Could not find file “/tmp/dup-28004bc8-4ed6-4071-8aa0-44ee35e1c5ae” (Could not find file “/tmp/dup-28004bc8-4ed6-4071-8aa0-44ee35e1c5ae”) (One or more errors occurred. (Error getting response stream (ReadDoneAsync2): ReceiveFailure)))” and backup stopped.
There is some files after this backup. But in main window I see than I have never done backup.
I tried two times with same result. What is it and how I can fix it?
Following the only clue provided, the ReadDoneAsync2 looks like Duplicati asked mono to do a WebDAV operation, and Yandex sent nothing (zero bytes), or possibly closed the connection at:
To actually see if a connection closed at the network level is possible if you’re willing to capture packets with tcpdump, wireshark, tshark, or similar. Encryption gets in the way of doing a good higher-level look.
You can possibly get a Duplicati-level look by looking either at About --> Show log --> Live --> Retry or <backup name> --> Show log --> Remote and click on the downloads and uploads around time of error. Possibly you can find a multiple-line stack trace which would say more about where Duplicati was then.
So to confirm, you’re saying you see new files showing up at Yandex, viewed somehow separately from Duplicati, and at some point things stop working? What does the status bar say at the time of the error?
Have you used the “Test connection” button on the Destination screen a few times? Does it run reliably? This is generally just a directory listing, so it might work even if uploads or downloads are having issues. Does the <backup name> --> Verify files button work well? That’s similar to the verification after backup.
In looking over past Yandex reports, I see reports in 2017 and 2018 that it worked, but recently it hasn’t. How’s your experience been on other systems (if you run any)? You might also have a system problem.
At least some of the above look like Canary versions (and yours is). I wonder if older Beta would work, although it’s got a lot of other problems? If you can test 18.104.22.168 or 22.214.171.124 to Yandex it may be helpful.
For a real guess on Canary, you could also try reducing --asynchronous-concurrent-upload-limit to 1 in case somehow the default 4 concurrent uploads causes an issue. Beta doesn’t do concurrent uploads.
Thanks for the additional client testing (and there are lots of others to try). Does the issue seem file size dependent, meaning can you get even a small file to work? Duplicati.CommandLine.BackendTester.exe has --min-file-size and --max-file-size, or try chosen files with Duplicati.CommandLine.BackendTool.exe.
Some prior posts showed you had Windows. Do you still, and does it show the same problem? If so, Network Tracing in the .NET Framework might be a way to get more information, without encryption preventing a view of the activity as one might get with packet capture (without special workarounds). There are probably some forum or GitHub posts that provide specifics. But be careful what you post.
First question I wonder about is did Yandex respond but Duplicati didn’t notice, or did it not respond?
If you feel like seeing whether timing is involved, you can set –throttle-upload and –throttle-download (which the code confuses, so setting both helps) to a low value to see if you can make 1 MB files fail.
All of this might well lead into you filing an issue with as much as you can get, and hoping somebody familiar with WebDAV (and maybe willing to open a Yandex account) can make further progress on it.