I’m running the latest beta (2.0.2.1). It was working until very recently, the last few days at most. AFAIK, I haven’t changed anything major recently, or even really updated anything except the command line tools for Xcode.
The menu bar icon shows up, but clicking on it then Open loads a completely blank page. I’ve already tried reinstalling the app, which required rebooting and preventing it from autostarting, because Finder claimed it was in use (yet nothing showed up in Activity Monitor, or when running ps -A).
Interestingly, Duplicati still seems to be running fine on 3 other devices (Macbook Pro—same OS, a Linux VPS, and Linux on a ReadyNAS), which have similar setups (same destination).
Duplicati: v2.0.2.1
OS: MacOS Sierra v10.12.6
Mono: ?? I’m honestly not sure how to check or update Mono
I’d really like to get this working again, because I need to get Duplicati set up on 3 other family computers I support (replacing Crashplan). This is making me very concerned, because I won’t always have ready access to them.
I noticed if I close the app, the web app now doesn’t load at all, so something is running at least. I don’t know if there are logs I can dig up or not.
Edit I found the SQLite files, but there’s nothing in them to indicate a failure. Looks like the last successful backup was today, so it’s possible the backups are still running.
Thanks for using Duplicati! Sorry to hear you’re suddenly having issues…when you say “blank page” do you mean in a web browser?
- Are you running the tray icon or as a service / daemon?
- Do multiple users have configured to start at login?
- If you run
mono -v in a terminal window what version of mono comes up? (Likely not the cause since it was working before).
- What web browser does the blank page load in?
How familiar are you with the command line (terminal)? It’s possible to try running Duplicati from the terminal which might show you some error messages that you’d normally find in the web interface…
1 Like
Hey there!
Yeah, in the web browser. It loads up with a literally empty page. Wait, I just inspected the page load, and apparently it’s returning a 400 error 400 BadRequest: Too large header value on line 8, let me check to see if there’s something happening client-side.
AH-HA I loaded it using a private tab, and it worked!
For completeness:
- Running using the tray icon
- Mine’s the only account on this machine (and the only one starting it)
Mono JIT compiler version 5.2.0.215 (d15-3/da80840 Thu Jul 20 16:43:07 EDT 2017)- Firefox (though from what I found above, I think it’s something slightly different)
So you can get in (via private tab) and confirm your backups are running, right?
I thought I remembered somebody else having a header related issue similar to yours, but I’m not finding it in my searches. 
We might have to wait until somebody more familiar with the web UI sees this.
OK, I confirmed the issue is cookies. I cleared the cookies for localhost, and the page loaded. This is obviously an error unique to the fact that I also develop against localhost, and for some reason, the cookies aren’t uniquely including the port as they should.
A couple of suggestions:
- Duplicati should probably render an error message if it can (if it had loaded
400 Bad Request, I might have narrowed it down faster)
- I wonder how hard it would be to configure something like
my.duplicati.com to point to 127.0.0.1, and use that instead of localhost? Obviously it’s pretty easy to add to the DNS, assuming someone has access to it. I don’t know if it would have any unexpected consequences.
Glad you got it figured out!
Just a few hours ago I was reading about another web UI project that had issues if cookies weren’t enabled and I almost thought to ask here if Duplicati used cookies. 
- The problem with a
400 Bad Request is that the browser can’t handle the response, so even if the server (in this case Duplicati) sent a user friendly message the browser would still not show it. (Though it might be visible in raw format via developer tools.)
- Adding something like that to a hosts file is doable, but presents a lot of potential side effects. For example, some people run tools that block updating of hosts files because some viruses and the like do such things.
Oof, I didn’t get any emails about this, I’ll have to see how to configure notifications.
At any rate, I meant set up the URL directly in the DNS used to resolve *.duplicat.com, not add it to the client’s hosts file. You can set any domain entry to point to 127.0.0.1 in a DNS server. I tried setting up local.overzealous.com as a test, though it hasn’t propagated as of submitting this, but I’ve used it in the past.
As far as the HTTP response, the server is free to return anything on any response code. The status code is separate from the body of the response. I made a quick test in Node using Express, the heart of which is
app.get('/', function (req, res) {
res.status(400).send('Hello World!');
});
This renders Hello World in the browser, but also returns a 400 status code. I can’t imagine any web framework not supporting this.
When I said a browser can’t handle a 400 Bad Request I meant it can’t do much beyond display what was returned from the server. If the server returns the full text of the Harry Potter books along with a statuscode of 400, sure - the browser will likely happily let you read all about Harry and his Henderson’s (oh, sorry - wrong thing, but still an Oscar winner).
So you’re right - the Duplicati server should be able to catch the error caused by the cookies and handle it better.
Sorry - I must have been thinking it was a 500 status code where the server totally crapped out and couldn’t respond with anything.
Sounds good! Thanks for your help. I’m very happy to finally have a backup tool I feel I can trust a bit better!
I wish I could help out more on the OSS-side of things, but I’m not a C# guy.
