2.0.4.5 server appears to be broken on Synology

Support
1

I’ve been happily using 2.0.3.9 on my Synology NAS for a while now, but after upgrading to 2.0.4.5, my backups are no longer running, and any attempt to connect to the server gets a perpetual “Connection lost, attempting again…” error.

Thinking it might be a database issue, I stopped the server, renamed the config directory, and let it create a new database from scratch, but I am still unable to connect.

Any suggestion where I should start looking? Can I reinstall 2.0.3.9, or has the database format been updated to where it’s no longer compatible with the earlier version?

Thanks,
Jon.

2

I am running 2.0.4.5 happily (apart from an old problem, I still haven’t figured out: How do I use --rebuild-missing-dblock-files ), on a DS214play, so maybee you problem is not synology related.

3

Hmm, I just tried upgrading 2.0.3.3 on my Synology to 2.0.4.5 and I have the same problem.

I also tried completely removing Duplicati from the Package Center, making sure all its processes were gone, and installing 2.0.4.5. It is running but I keep getting the connection lost message.

So far I’ve only tried 2.0.4.5 on two machines and have had poor results on both. Back to 2.0.3.3 for now.

4

specific.[quote=“drwtsn32, post:3, topic:5576”]
Back to 2.0.3.3 for now.
[/quote]
Sorry, but 2.0.3.12 is as far back as you can easily “in-place” downgrade from 2.0.4.6. If you’re willing to note global settings, export/import your jobs, and wait for database RECREATE to finish you could probably do so…

Depending on what’s been done since the update restoring the backup databases and using REPAIR might work, but I haven’t tested that.

I think some (but not all) other users have reported a similar issue on noon-NAS hardware so this is likely not Synology specific.

5

Before I upgraded from 2.0.3.3 to 2.0.4.5, I copied (as a backup) the Duplicati config folder that contains the databases. Since the upgrade was not really successful, I uninstalled 2.0.4.5, restored the backup of the Duplicati config folder, and then reinstalled 2.0.3.3.

This is going to be my SOP for any upgrade attempt. Also thought about setting the global dry-run option too, to potentially spot any issues before the remote storage is modified by a new version.

6

I tried looking at this Synology issue again, but didn’t make any headway.

I removed 2.0.3.3 and renamed the Duplicati data folder. Then installed 2.0.4.5 clean to see if it would operate correctly. The Web UI still gives the “Connection lost…” message frequently.

The Duplicati process is running on the NAS - it’s not like it crashed as far as I can tell.

Any suggestions on how to troubleshoot this further?

By the way - another issue with the Synology package seems to be that the Duplicati service does NOT stop when you tell it to stop from the Synology Package Manager. I still see it running when I do a “ps ax”. If I kill the PID then it stops as expected (I don’t have to force kill it).

7

Time to circle back around to this. My three individual jobs are all working fine from the command line, but I remain unable to connect to the server when I start it via the Synology Package Center. However, if I start the server manually from the command line by running
mono /volume1/@appstore/Duplicati/Duplicati.Server.exe --webservice-interface=*
from the package’s target directory, then I can connect to it on port 8200 and all functions appear normal.

So it would appear to me that this is indeed a problem with the Synology implementation, and I’d love to be proactive and try to help diagnosing the problem, but I don’t know where to start. Any suggestions greatly appreciated.

8

Take a look to see how many Duplicati processes are there while Duplicati is fully up. If two, my theory is at
Can’t connect to DSM started Duplicati after Synology 6.2 update
and a similar Server issue is on Windows Command Prompt where a Control-C kills parent but leaves child.

9

The Synology package manager fires off a mono command to start the server. That in turn spawns a mono-sgen process which actually does all the work. The issue is that when you use the Package Center to stop the server, it kills only the original mono process, while the child process - and thus the server - continues to run. But this is no different from how it used to work with 2.0.3.9 - it may not be ideal but it’s not something that was introduced with 2.0.4.5, and I don’t believe it’s related to the inability to connect to the server.

1 Like
10

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?

11

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.

12

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

13

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
14

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
15

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
16

Thanks for putting that instruction set together!

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

17

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?

18

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

19

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

20

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?