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. 
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.
Maybe some admin can seperate the shutdown issue from the no connection problem? Or is there a correlation between them?
Likely not a correlation, and from what I saw many of the posts talk about both making it hard to split.
Yeah no correlation. It was just another Synology issue. Apologies for muddling this thread!
One last thing to add, which I discovered after applying the latest DSM security update tonight: you must be logged in to DSM in order to be able to see the full server details in the Duplicati web interface.
I had it open in a separate tab, and after rebooting the NAS I could only see a blank Duplicati server with no scheduled tasks, until I switched to my DSM tab and logged back in. Makes sense when you think about it since the web interface is going through Synology’s front-end proxy, but a trap for young players if you’re not expecting it.
Wait what? I have never noticed that. I’m rarely logged in to DSM. I access Duplicati web interface via a remote PC. Isn’t the Duplicati web interface handled by its own “web server” engine?
However after rebooting I find I do need to start the Duplicati service manually (via Package Center). It never seems to auto-start.
Well that’s certainly the way it’s working for me - in fact if I log out of DSM then Duplicati reverts to showing me an empty server. Are you perhaps accessing the server directly on port 8200 instead of through the “official” URL for the Syno package, https://[NAS]:5001/webman/3rdparty/Duplicati/ngax/index.html#/ ?
Yes, that’s exactly right. I had no idea about that “official” URL! What are the main reasons for using one over the other?
In reality, probably none, but it’s the URL that DSM sends you to if you use their menu -
as I suspect most folks do after installing it from Package Center unless they’re already familiar with Duplicati on some other platform. I know I only discovered port 8200 while I was struggling to diagnose the problem that started this whole thread - I had simply bookmarked the other URL after DSM sent me there the first time.
Hi
Thanks for the tip.
For both URL’s (See below), it’s not working - or… Well… It works for a few sec. I’m able to navigate through the options, but hereafter this shows up:
http://[SYNO-IP]:5000/webman/3rdparty/Duplicati/ngax/index.html#/settings
https://[SYNO-IP]:5001/webman/3rdparty/Duplicati/ngax/index.html#/settings
If i navigate to About, i’m able to open up the tabs, before i got the Connection Lost:
But fx. About > Show log > Stored is just stuck at “Loading”…
After Connection lost shows up, i can simply reload the page, and the GUI works again.
I can see that the error shows up after a call to: https://[SYNO-IP]:5001/webman/3rdparty/Duplicati/api/v1/serverstate/?lasteventid=-1&longpoll=false&duration=299s, and the check for serverstate goes over and over again:
I’ve tried to find log-files in /var/packages/Duplicati but i can’t find anything usefull. And i can’t find anything interesting in /var/logs.
If i look for mono /volume1/@appstore/Duplicati/Duplicati.Server.exe in top, i’m able to find it under pid 9640.
Can you check the CPU level on your Synology? I’ve noticed if my CPU is pegging on my unRAID box then my Duplicati Docker container tends to show the “connection to the server is lost message”.
It’s actually happening to me right now - and oddly most of the CPU is being taken by Duplicati (which is OK - as I’m stress testing). 
3-6 procent CPU. It’s almost at idle. Meeeeh. But. thanks for the point!
I’m not sure what i can do. Any advices?