2.0.4.5 server appears to be broken on Synology

Do Synology users always run the Duplicati UI remotely? Although your symptoms sound different, security is tighter than it used to be, to prevent a class of exploits, and this has required some changes of remote users.

Duplicati upgrade - “The host header sent by the client is not allowed”

If Synology Package Manager is still on the script I linked to in the “Can’t connect” article, it lacks the options you supplied manually, in addition to the new --webservice-allowed-hostnames=* that might be needed.

It would be useful to know if there’s a TCP-level issue, e.g. by using telnet or a new browser tab to the port. Those will avoid our having to guess at exactly what the Duplicati browser code means when it gives an error.

Is that saying it comes and goes within a Duplicati run, or Duplicati starts only sometimes, or something else?

I usually do, but sometimes I run Duplicati UI on the Synology UI itself.

Duplicati process starts ok, I just can’t connect to it reliably either locally or remotely. I get Connection Lost messages either way.

Interesting line of thought. I’ll start it again via the Syno package manager and try various modes of access. Back soon…

OK, after starting the package I see…

root@Tower:/var/packages/Duplicati/target# ps -ef |grep mono
root     16092     1  0 22:25 ?        00:00:00 mono /volume1/@appstore/Duplicati/Duplicati.Server.exe
root     16104 16092  1 22:25 ?        00:00:01 /volume1/@appstore/Mono/usr/local/bin/mono-sgen /volume1/@appstore/Duplicati/Duplicati.Server.exe
root     22489 11123  0 22:27 pts/26   00:00:00 grep --color=auto mono
root@Tower:/var/packages/Duplicati/target# netstat -an |grep 8200
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:8200          127.0.0.1:34405         TIME_WAIT
tcp        0      0 127.0.0.1:34410         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34403         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34405         127.0.0.1:8200          TIME_WAIT
root@Tower:/var/packages/Duplicati/target# netstat -an |grep 5001
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.11:5001       192.168.0.8:64619       ESTABLISHED

If I attempt to connect to if from within the Synology DSM UI, I get Connection lost, attempting again in… almost immediately, and I see

root@Tower:/var/packages/Duplicati/target# netstat -an |grep 8200
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:8200          127.0.0.1:34468         TIME_WAIT
tcp        0      0 127.0.0.1:8200          127.0.0.1:34459         TIME_WAIT
tcp        0      0 127.0.0.1:34465         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34470         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34475         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34472         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:8200          127.0.0.1:34464         TIME_WAIT
tcp        0      0 127.0.0.1:34460         127.0.0.1:8200          TIME_WAIT
root@Tower:/var/packages/Duplicati/target# netstat -an |grep 5001
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.11:5001       192.168.0.8:64619       ESTABLISHED

If I kill that window and use the DSM GUI to “Open in a new window”, which points my browser at https://tower.my.domain:5001/webman/3rdparty/Duplicati/ngax/index.html, then again I get Connection lost, attempting again in… almost immediately, and see

root@Tower:/var/packages/Duplicati/target# netstat -an |grep 8200
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:34595         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34601         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34589         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:8200          127.0.0.1:34601         TIME_WAIT
tcp        0      0 127.0.0.1:8200          127.0.0.1:34605         TIME_WAIT
tcp        0      0 127.0.0.1:34598         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34596         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34591         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34604         127.0.0.1:8200          TIME_WAIT
root@Tower:/var/packages/Duplicati/target# netstat -an |grep 5001
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.11:5001       192.168.0.8:65407       ESTABLISHED

Which is interesting because I would now expect to see two connections from my PC (192.168.0.8) - one to the DSM UI and another to Duplicati.

If I then edit the URL to use the IP address instead of the DNS name - https://192.168.0.11:5001/webman/3rdparty/Duplicati/ngax/index.html - then I still wind up in a Connection lost, retrying… loop, but this time the whole process is in normal time - I actually see the server interface for a couple of seconds initially, then Connection lost, Connecting to server… for a second or so, then Connection lost, retrying in… again, then looping between the two Connection lost messages ad nauseum but at “normal” speed.

While this is going on, I see

root@Tower:/var/packages/Duplicati/target# netstat -an |grep 8200
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:34825         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34817         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34812         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:8200          127.0.0.1:34821         TIME_WAIT
tcp        0      0 127.0.0.1:34813         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34819         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:34826         127.0.0.1:8200          TIME_WAIT
root@Tower:/var/packages/Duplicati/target# netstat -an |grep 5001
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.11:5001       192.168.0.8:65407       ESTABLISHED
tcp        0      0 192.168.0.11:5001       192.168.0.8:49781       ESTABLISHED

(Aha, there’s that second session from my PC!)

If I now change the URL again to point to Duplicati directly instead of the redirect that Synology would have me use - http://192.168.0.11:8200/ngax/index.html#/ - then I get the exact same sequence as the previous attempt - initial view, then connection lost loop in normal time, and I see

root@Tower:/var/packages/Duplicati/target# netstat -an |grep 8200
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:8200          127.0.0.1:35027         TIME_WAIT
tcp        0      0 192.168.0.11:8200       192.168.0.8:51136       ESTABLISHED
tcp        0      0 127.0.0.1:35030         127.0.0.1:8200          TIME_WAIT
tcp        0      0 192.168.0.11:8200       192.168.0.8:51134       ESTABLISHED
tcp        0      0 192.168.0.11:8200       192.168.0.8:51140       ESTABLISHED
tcp        0      0 127.0.0.1:35027         127.0.0.1:8200          TIME_WAIT
tcp        0      0 192.168.0.11:8200       192.168.0.8:51130       ESTABLISHED
tcp        0      0 127.0.0.1:35024         127.0.0.1:8200          TIME_WAIT
tcp        0      0 192.168.0.11:8200       192.168.0.8:51761       ESTABLISHED
tcp        0      0 192.168.0.11:8200       192.168.0.8:51135       ESTABLISHED
root@Tower:/var/packages/Duplicati/target# netstat -an |grep 5001
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.11:5001       192.168.0.8:65407       ESTABLISHED

And finally, if I change the URL once more to point directly to the server by DNS name, then I get The host header sent by the client is not allowed, and see

root@Tower:/var/packages/Duplicati/target# netstat -an |grep 8200
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:35065         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:35058         127.0.0.1:8200          TIME_WAIT
tcp        0      0 127.0.0.1:8200          127.0.0.1:35061         TIME_WAIT
tcp        0      0 127.0.0.1:35068         127.0.0.1:8200          TIME_WAIT
root@Tower:/var/packages/Duplicati/target# netstat -an |grep 5001
tcp        0      0 0.0.0.0:5001            0.0.0.0:*               LISTEN
tcp        0      0 192.168.0.11:5001       192.168.0.8:65407       ESTABLISHED

What is interesting is that in the brief initial periods when the server UI is visible it shows no backups or scheduled tasks, so it’s presumably not using the correct server database though I can’t find any other instance of Duplicati-server.sqlite anywhere.

1 Like

Nailed it!

I stopped the Syno package and started the server from the command line again, then added my NAS’s DNS name in the Hostnames setting and verified that I could now access the UI at http://tower.my.domain:8200/ngax/index.html#/.

I then stopped it and restarted the Synology package, and lo and behold, everything works! I see the full UI, with my backups and scheduled tasks, regardless of whether I point directly to the server at port 8200 or to the Synology redirected port at https://tower.my.domain:5001/webman/3rdparty/Duplicati/ngax/index.html

So it seems that the extra Hostname security setting is the culprit after all.

1 Like

So to summarize, for anyone else suffering the same problem, this appears to be an incompatibility between the Synology integration and the upgraded security introduced in 2.0.4.5. Until it gets fixed officially, this workaround worked for me, and should get you back up and running:

  1. Stop the Duplicati package from the Synology Package Center.
  2. Check for any server process still running, and kill it, eg:
    root@Tower:/var/packages/Duplicati/target# ps -ef |grep mono root 18002 1 10 Dec24 ? 01:43:25 /volume1/@appstore/Mono/usr/local/bin/mono-sgen /volume1/@appstore/Duplicati/Duplicati.Server.exe root@Tower:/var/packages/Duplicati/target# kill 18002
  3. SSH to the NAS, log in as root, and cd to the installation directory:
    cd /var/packages/Duplicati/target
  4. Start the server from the command line, listening on all interfaces:
    mono /volume1/@appstore/Duplicati/Duplicati.Server.exe --webservice-interface=*
  5. Access the server directly, using the IP address of the NAS, e.g. http://192.168.0.11:8200
  6. Click on Settings, and enter your Synology’s DNS name, e.g. tower.my.domain in the Hostnames field, then scroll to the bottom of the page and click OK.
  7. Kill the server process with Ctrl-C.
  8. Check for and kill any server process still running, per Step 2 above.
  9. Start the package from the Package Center.

That’s what worked for me. No guarantees, but it should get you up and running.

2 Likes

Thanks for putting that instruction set together!

I assume in step 6, the DNS name supposed to go in the “Hostnames” field, right?
image

I had already entered the hostname in the 2.0.4.5 settings page, but that alone doesn’t solve the issue.

You are saying that for now you have to manually start the Dupicati server instead of using Package Mgr to fully work around the issue?

Never mind, I guess you say you can still start it from Package Mgr in step 9. So I don’t really think this is a solution. I was able to get the hostname configured but I still have the Connection Lost issues. Hmmmm

Yes. Thanks for pointing out my omission - I’ve updated the instructions accordingly.

Ugh, I guess there are more forces at play here; sorry it doesn’t work for you. Have you tried putting * in the Hostnames field?

No, I haven’t tried that. I’ll do more experimenting tonight and report my results!

I tried your workaround this morning and I had success with it! Maybe I wasn’t actually able to set the hostname field before - I may have been thinking of another headless Linux system I have.

Thanks for the workaround!

I think I fixed this issue and submitted a new pull request:

Would appreciate someone else testing it. I only have one NAS to test it on, but it works for me.

1 Like

Thanks for that - I manually applied your change to my system and it appears to work perfectly.

I tried to add my external dns name, my internal IP, the *
If I then start up with the package manager, I get kind of a “empty” (e.g. my backup job is not shown) duplicati webinterface for some secondy and then again “connection lost”.

Nothing helps, the only way getting it running is starting manual on command line with
mono /volume1/@appstore/Duplicati/Duplicati.Server.exe --webservice-interface=*

But I want to close my ssh terminal. Adding & or prefixing the command above with nohup doesnt work - so I added a cronjob using DSM - Control Panel - task scheduler to start the command. I think that works for the time being.

I’m not fully tracking everything here and have no actual Synology experience so forgive me if this is a silly question. :slight_smile:

Is this issue pre-existing or did a DSM update “cause” it? If the latter, will your fix cause any issues on older versions of DSM?

Lastly - just to clarify, your fix is for the issue with restarting Duplicati (such as during updates) not for the problem of not being able to connect from an external source.

This was just a fix for the issue where Duplicati processes aren’t stopped properly by DSM package center. It has nothing to do with the other “connection lost” issue.

Also I’m not sure how long this problem existed. I rarely stop the Duplicati services on DSM but I believe I’ve noticed this issue for at least a year.

This sounds similar to a lot of MacOS experiences…would this fix potentially apply there as well or does it only run on DSM?

The file I updated on GitHub is a startup/shutdown script for DSM specifically. I’m not familiar with OSX at all so I don’t know what method is used to terminate Duplicati. If it’s “kill” and OSX uses Mono, it may certainly be the same issue that affected DSM. In that case maybe the same or similar fix could be applied.