After I switched from Canary- to Beta-channel and updated DUPLICATI, the GUI is no longer accessible.
(Firefox can not connect to the server under localhost: 8200.)
Update from:
Version v2.0.3.2-2.0.3.2_canary_2018-03-16
to:
Version v2.0.3.3-2.0.3.3_beta_2018-04-02
That is actually (at least with regard to the version numbers) the correct procedure, right?
I remember that after the update, everything seems to work, but clicking âactivate updateâ showed
no effect, so in âaboutâ it showed still the previous version as current installed version. After a Windows
reboot, the GUI was not more accessible.
Attempts so far to (not) solve the problem: - check if the DUPLICATI server is running in âWindows Servicesâ (yes, ok!) - restart DUPLICATI server - stop, then start DUPLICATI server - over-installation - repair-installation - stop DUPLICATI server, then run Duplicati.GUI.TrayIcon.exe (nothing happend) - reboot (several times)
Today I uninstalled Duplicati (including service), restart my system and installed (default installation) Duplicati again, but again ⌠nothing(!) happens. The tray icon is not there after system startup, manually starting the Duplicati.GUI.TrayIcon.exe effects also nothing.
There is also no indication in the Task Manager that Duplicati is running.
Ok, then it seems that Duplicati isnât running at all. (hence no access to the gui).
But thatâs a bit out of my knowledge since you already de- and reinstalled the whole thing.
Perhaps one of the other guys has an idea (@JonMikelV)?
Further experiences:
I have now restored a system backup where DUPLICATI worked. But then comes the sticking
point! If I now install the Beta (this time not over GUI > setup file) exactly the same mess occurs:
I call the GUI, itâs still âCanaryâ and after rebooting the system ⌠kaboom, nothing more / no gui!
Observations:
The system load is higher - not really noticeable, but audible. (Fan runs faster)
Iâd recommend we start by getting some log info.
Probably the easiest way would be to run the following from a command prompt and see if you get any details about an error: "C:\Program Files\Duplicati 2\Duplicati.GUI.TrayIcon.exe" --verbose
Alternatively, you could create a log file with something like the following to generate a log file in your Downloads folder: "C:\Program Files\Duplicati 2\Duplicati.GUI.TrayIcon.exe" --verbose --log-file="%userprofile%\Downloads\Duplicati.log" --log-file-log-level=Profiling
I am having a similar problem with the Docker version of Duplicati.
I am running 2.0.3.3_beta_2018-04-02 and I just started getting this error in the logs:
âA serious error occurred in Duplicati: System.UnauthorizedAccessException: Access to the path â/tmp/HttpServerâ is denied.â
I am unable to access the GUI.
It was working just yesterdayâŚ
If I then make a subfolder called âHttpServerâ in the containerâs director mapped to Duplicatiâs âtmpâ folder, then it works. And I get the GUI.
It appears to me that Duplicati has switched from looking for the HttpServer folder in the specified â/tmpâ folder to looking for it in the specified â/backupsâ folder.
So I can back up using this Duplicati version on Windows. However, running the Docker version (same 2.0.3.3._beta_20188-04-02), in addition to the /tmp/HttpServer denied error above, after implementing the above workaround, I then get this error:
Fatal error
System.UnauthorizedAccessException: Access to the path "/tmp/dup-70b4434a-7b93-4e4a-b33f-591dc733e09a" is denied.
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0019e] in <9bbab8f8a2a246e98480e70b0839fd67>:0
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize) [0x00000] in <9bbab8f8a2a246e98480e70b0839fd67>:0
at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int)
at System.IO.File.Create (System.String path, System.Int32 bufferSize) [0x00000] in <9bbab8f8a2a246e98480e70b0839fd67>:0
at System.IO.File.Create (System.String path) [0x00000] in <9bbab8f8a2a246e98480e70b0839fd67>:0
at Duplicati.Library.Utility.TempFile..ctor (System.String path) [0x00021] in <0828ce86ffa94a4bbbb2da4331bcc67b>:0
at Duplicati.Library.Utility.TempFile.CreateInFolder (System.String path, System.Boolean autocreatefolder) [0x0001d] in <0828ce86ffa94a4bbbb2da4331bcc67b>:0
at Duplicati.Library.Main.Volumes.VolumeWriterBase..ctor (Duplicati.Library.Main.Options options, System.DateTime timestamp) [0x0001b] in <ae134c5a9abb455eb7f06c134d211773>:0
at Duplicati.Library.Main.Volumes.FilesetVolumeWriter..ctor (Duplicati.Library.Main.Options options, System.DateTime timestamp) [0x00000] in <ae134c5a9abb455eb7f06c134d211773>:0
at Duplicati.Library.Main.Operation.BackupHandler.Run (System.String[] sources, Duplicati.Library.Utility.IFilter filter) [0x002ad] in <ae134c5a9abb455eb7f06c134d211773>:0
It seems the temp folder mappings are wrong.
Iâve tried uninstalling the docker and deleting its config and temp files, then reinstalling, but does not fix the problem.
When I run the command and check the taskmanager, the program-file is briefly displayed and is gone a few seconds later.
Sorry that I have to give up at this point. Very unsatisfactory not to have recognized the evil of the whole probably it has something to do with the person in front of the monitor. But I do not know what I could have done wrong. It seemed to be foolproof ⌠doing an update, pah!
I will wipe everything which belongs to Duplicati and then I (try to) install the current beta. I will report âŚ
Iâm running Duplicati 2.0.3.3 beta in a Docker container (the official container, though until recently I was running linuxserver one) on an unRAID 6 system and have had no troubles as recently as today. Do you recall what changed (Docker version, OS, etc.) between when it last worked and when it stopped working?
HmmmâŚthatâs unexpected⌠I recently had a similar experience (no log contents) with the recovery tool, but I just figured logging hadnât been added to that.
For the updates you were doing (2.0.3.2 canary to 2.0.3.3 beta) there should indeed have been
no issues, so Iâm not really sure what happened either.
If youâre doing a FULL wipe, just remember that some settings / sqlite files live if different folders depending on whether you are running as service with âLocal System Accountâ user, tray-icon / service as a different user, or in --portable-mode.
probably it has something to do with the person in front of the monitor. 
But I do not know what I could have done wrong. It seemed to be foolproof ⌠doing an update, pah! 
