FTP: Failed to connect, Win10

If I create a new backup task and test the connection, it fails with message ‘Failed to connect: Die zugrunde liegende Verbindung wurde geschlossen: Der Server hat eine Protokollverletzung ausgeführt…’ (Translation of German message part: The underlying connection has been closed: the server has performed a protocol violation).

  • Connection check with FileZilla is ok
  • I don’t use SSL
  • The disk station protocoll (destination device) shows sucessfull login
  • Now I use Win10, but I used the same Duplicati-Version sucessfully before with Win7. At the time I run Win7 I saved my backup task to a file, updated my PC to Win10, and if I restore the saved backup task and test the connection … I get ‘Failed to connect’.

I use Duplicati version ‘’.

So what is wrong? Any hint welcome :slight_smile:

Welcome to the forum @Eddy

I don’t know why Windows version makes a difference, except possibly for .NET Framework versions which seem to go up periodically (but Windows 7 also gets updated, I think). FTP, if that’s exactly the Storage Type you’re on, is .NET Framework. Have you tried using FTP (Alternative) instead of that? There’s an even newer version of that third-party FluentFTP client in the Beta that came out today…

There are also options on both clients that you can play with, and some debugtest tools if need be…

Hello ‘ts678’,
thanks for your response.

How to get debug information? I set general option ‘debug-output’ = X, but I assume this is not related to ‘Test Connection’. At least the output is the same.

  • Now I tried storage type FTP (Alternative) and at least the connection test was successfully. Just that I don’t know AFTP and that the test tooks around 60s which makes me struggeling a little bit.
  • I also check the FTP permissions, at all directories 777. So no issue at this point, I was also able to create a file with the relevant user acount.

Now, the point which makes me wonder again: I want to save the data in a 2nd level sub directory (e.g. /Backup/duplicati).

  • If I change the server path to ‘/Backup’, now the ‘Test connection’ works
  • If I change the server path to ‘/Backup/duplicatiX’ a new directory will be created and ‘Test connection’ works
    … just it doesn’t work at the server path which I used before I switched from Win7 to Win10…

So might be a bug on duplicati side, but might be something else. I’m getting doubts if duplicati is reliable enough to be used as backup tool. But maybe with your help I get it done.

me again :wink:

I found some debug information and this points again to a bug. As I use a German version of Win10 Pro, also the error messages which are send back from .NET are in German… English translation of the key response is ‘System.ObjectDisposedException: You cannot write to a closed TextWriter.’

Jan 18, 2020 6:16 PM: Reporting error gave error
System.ObjectDisposedException: In einen geschlossenen TextWriter kann nicht geschrieben werden.
bei System.IO.__Error.WriterClosed()
bei System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
bei Duplicati.Server.WebServer.RESTHandler.DoProcess(RequestInfo info, String method, String module, String key)

What’s there to know? It’s a different (alternative) FTP client, just like Filezilla is a different FTP client. There are enough possible variations in FTP protocol use that sometimes one works if another won’t.

How does path differ from the two that worked? Can you show it, or a similar path that isn’t working?
Can you say what “doesn’t work” looks like from its behavior, or error messages? Too little info here. While I don’t know how a Windows change changes anything, could you adapt the old path to work?

The one message that you gave looks like a generic error which is not the FTP error you want fixed. Maybe it is a secondary error? A good debug method is FTP server log, comparing good and bad… Your server apparently logs logins. Can it also log uploads, downloads, directory listings, and so on?

Duplicati.CommandLine.BackendTester.exe is an automated test that needs an empty folder to use.

Duplicati.CommandLine.BackendTool.exe can be used for manual testing of the specific operations.

Both of these require a URL which is probably similar to what a job Export As Command-line shows.

One point I’d mention is that one or both of these FTPs dislikes spaces in the path (probably a bug). Testing now, I think it’s FTP (Alternative) where error popup when I try Test connection to it is

Failed to connect: CWD failed. "/ftp%20test%201": directory not found.

The space becomes its numeric equivalent hexadecimal 20, percent-encoded, and confuses server.

There is also a chance the firewall settings of Windows 7 weren’t replicated on Windows 10, but the successful tests are evidence against a firewall problem. Right now, some paths work, others don’t?

Please see below second Duplicati Log item which I had overseen so far. But this is just for documentation, at the end it shows not so much more than stated at the beginning: ‘The underlying connection has been closed: the server has performed a protocol violation’

Jan 18, 2020 6:16 PM: Request for http://localhost:8200/api/v1/remoteoperation/test gave error
System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Der Server hat eine Protokollverletzung ausgeführt…
bei System.Net.FtpWebRequest.DataStreamClosed(CloseExState closeState)
bei System.Net.FtpDataStream.System.Net.ICloseEx.CloseEx(CloseExState closeState)
bei System.Net.FtpDataStream.Dispose(Boolean disposing)
bei System.IO.Stream.Close()
bei Duplicati.Library.Utility.OverrideableStream.Dispose(Boolean disposing)
bei System.IO.Stream.Close()
bei System.IO.StreamReader.Dispose(Boolean disposing)
bei System.IO.TextReader.Dispose()
bei Duplicati.Library.Backend.FTP.d__20.<>m__Finally1()
bei Duplicati.Library.Backend.FTP.d__20.System.IDisposable.Dispose()
bei Duplicati.Library.Interface.BackendExtensions.TestList(IBackend backend)
bei Duplicati.Server.WebServer.RESTMethods.RemoteOperation.TestConnection(String url, RequestInfo info)
bei Duplicati.Server.WebServer.RESTHandler.DoProcess(RequestInfo info, String method, String module, String key)

I’m comming closer to the root cause… :wink:

Points which I checked in addition:

  • At the server, the Protocoll-Center shows message no issue. (‘User [xxx] from [192.168.0.xxx] logged in successfully via [FTP].’ , ‘FTP client [xxx] from [192.168.0.xxx] logged out the server with totally [0 bytes] uploaded and [0 bytes] downloaded.’
  • Owner of the target FTP directory at the server is the login user. Again, no permission issue.
  • Updated to last Duplicati version no change
  • Checked with Windows Event Viewer on client side: no issue visible
  • Turned off the Firewall on client side: no change
  • set FTP option ‘ftp-passive’ = X at Duplicati : no change
  • Set FTP option ‘ftp-regular’ = X at Duplicati : no change

What I figured out is, that the issue is dependend to the amount of files which are already existing at the destination path.

  • My original destination path was '/Backup/duplicati’, with 231 GB data. The test connection fails.
  • At a new and empty destination path '/Backup/duplicatiX’, I had no issue, the test connection is sucessfull.
  • At destination path '/Backup/duplicatiX’ with a single file, I had no issue, the test connection is sucessfull.
  • At destination path '/Backup/duplicatiX’, with the same 231 GB data as my original destination path, I had my issue again , the test connection fails!
  • After I deleted step by step the files again at path '/Backup/duplicatiX’, approx at 1 GB I found the border. With approx 1 GB data it worked again. The test connection was sucessfull.

Sounds funny, but is reproducable.

Is the 1 GB at default 50 MB remote volume size? Some FTP servers take issue with lots of files, but

20 dblock of 50 MB
20 dindex, one per dblock
1 dlist

seems too soon if that’s about what’s there. The typical Duplicati Test connection just lists the files (whose time may vary), but FTP (Alternative) does a fancier test for some reason, so also tries to verify that a file upload and download work. Code is here. Write and read seem even less likely to be sensitive to the existing file content though. Best debug is technical, Wireshark on port 21 to watch it. Easy to watch, if it’s all in clear text (encryption is optional), but be careful about anything you post…

I wasn’t able to analyse in the last weeks, but today I’m back ;-).

I installed Wireshark and figured out that with destination storage type ‘FTP’, the code behind the button ‘test Connection’ has an issue with many files in the target directory. After approx 130 of 8800 files (11706 bytes FTP-DATA), the LIST command stops unexpected and the FTP connection ends without ‘FTP request: QUIT’ at the end. The root cause might be also on the side of my Synology Disk Station.

I tested destination storage type ‘FTP (Alternative)’ too. It works. With this option a more modern FTP style is used and a check which includes also a verification of write permissions. More ‘modern’ FTP, because ‘newer’ FTP-Comamnds are used (FTP commands like MLSD, EPSV, STOR, FEAT instead of e.g. PASV, LIST).

So I hope if someone else has the same issue, he will find this thread usefull for his analysis. I will go for ‘FTP (Alternative)’, now. Hopefully there is no other issue waiting for me… :slight_smile:

Thanks to TS678!

Thanks for the update. Some FTP servers are believed to not do large directory listings well (and some Microsoft cloud servers are the same way…). Until such time as a subfolder scheme is in place, having Remote Volume Size on screen 5 Options be larger is a workaround. Using a different FTP client is an interesting idea though. Credit for any FTP (Alternative) improvements go to the FluentFTP project.