I’m running Debian Sid (Trixie), and I can’t use Dupicati 2.07 nor 2.08. Duplicate 2.07 was working fine with Sid until a couple months ago, when I could no longer connect to localhost:8200
drfox@lapdog:~/Downloads$ sudo dpkg -i duplicati_2.0.8.1-1_all.deb
Selecting previously unselected package duplicati.
(Reading database ... 198700 files and directories currently installed.)
Preparing to unpack duplicati_2.0.8.1-1_all.deb ...
Unpacking duplicati (2.0.8.1-1) ...
dpkg: dependency problems prevent configuration of duplicati:
duplicati depends on libappindicator0.1-cil | libappindicator3-0.1-cil | libayatana-appindicator1; however:
Package libappindicator0.1-cil is not installed.
Package libappindicator3-0.1-cil is not installed.
Package libayatana-appindicator1 is not installed.
duplicati depends on gtk-sharp2; however:
Package gtk-sharp2 is not installed.
dpkg: error processing package duplicati (--install):
dependency problems - leaving unconfigured
Processing triggers for desktop-file-utils (0.27-2) ...
Processing triggers for gnome-menus (3.36.0-1.1+b2) ...
Processing triggers for mailcap (3.70+nmu1) ...
Errors were encountered while processing:
duplicati
I don’t care about a tray icon (I use gnome) It seems to install OK, but when type in http://localhost:8200/ngax/index.html, I get an unable to connect error. You should let users know to run “Duplicati” from the apps menu the first time it’s run
Where are my backup configs (tasks?) stored so I don’t have to create new ones?
Installing Duplicati on Linux in the manual also covers it, but a key question is – which user do you need, because starting as you from an apps menu won’t have as much file access privilege as a root service.
Things were working well until a few days ago. Now, one of my 3 profiles is stuck and the other 2 can’t run because of it. I’ve tried “Stop now” and “Stop after the current file” and neither works. I have tried moving the “stuck” video to a new location (it moves), but that did not solve the problem.
I looked in ./.config/Duplicati and there’s nothing there which I feel I can fiddle with.
I suspect there’s something I can stop in “System Monitor”, but I don’t know what. Obviously, I’m running Linux (Sid, Trixie) with Gnome.
Thanks for any help you can give me…below is a screenshot
You should be able to stop duplicati or duplicati-server, depending on how you are running it.
But it would nice to understand why it is stuck, so we can prevent that from happening in the future.
If you go to “About” and “Show log”, do you see any messages?
Thank you for the quick response. Unfortunately there is no duplicati* listed in System Monitor. There is quite a bit in the logs. I’ve attached them from latest to earliest
System Monitor menu appears to default to showing “My Processes” not “All Processes”.
What user is Duplicati running as? If in doubt, also see About → System info UserName.
You were absolutely right about System Monitor showing My Processes; I switched to All Processes, found duplicati-server, killed it, and now the other backups seem to be working as configured.
If I have any more problems running the backup which failed, I’ll write back tomorrow.
was kind of unclear, as it didn’t say current directory, but was probably some user’s home directory, then
suggests that the recently updated databases would be in ~root/.config/Duplicati, although there’s nothing there that’s meant to normally be fiddled with. One concern is that backing up the local database path will open the database for reading through (just like any other file), and may interfere with access as database.
posted above has the “look” of some sort of interference, but the stack trace is hard for me to understand, however ListFilesHandler says maybe it was listing destination files. This would likely be an early step. Any feel for how far it got before it got stuck? There are probably a few clues around, if we have to go dig.
The backing-up-the-database theory could easily be ruled out if you know you’re not doing it, and an early stuck situation would also suggest it’s something else, maybe some Duplicati pre-start cleanup stepping onto the start of the actual backup. I thought I’d seen a fix for that, but now I see that it’s not gotten in yet:
This theory could be supported or refuted if you know if you set auto-cleanup in job’s Advanced options:
Best clues are from a log-file at some log-file-log-level, maybe Verbose, but it needs to be set beforehand.
System Monitor has a Search for Open Files feature which might be handy to see if the job database was open during the time it was stuck. That’s another thing that can be done, but only if issue happens again…
