After update and fingerprint issue: backups gone

Hi everyone!
I recently updated to version My OS is an Arch distribution (kernel 6.6.22-1-lts).

I was getting a warning about failed validation of fingerprint (I am using sftp to run backups):

Validation of server fingerprint failed. Server returned fingerprint 
"ssh-ed25519 256 f0:5d:43:77:9c:06:d3:....". Cause of this message is either not correct configuration or Man-in-the-middle attack! 

I double-checked the fingerprint - and it is ok. In the settings of my backup, I tested the connection and approved the “new” fingerprint. When manually initiating the backup afterwards, the error reappeared.
with the following commands, I restarted duplicati:

systemctl stop duplicati
systemctl start duplicati
systemctl status duplicati

Duplicati welcomes me as if it was a fresh installation. All settings, including the backups are gone. I tried to import one of my backups from a local sqlite-file, but after 1hour with CPU-usage of 0%, I cancelled.

This is what my config-folder looks like:

Before I make things worse, I thought I ask you guys for help. How can I restore my backups? I can’t believe that the stuff got actually deleted. Thanks in advance for helping.

Did you see this then?


That’d be pretty strange. It means you have no server database (Duplicati-server.sqlite).
An easy way to get that is to change users by accident, but has user always been root?

How? From a popup invitation in Duplicati GUI to update? By an Arch package install?
The AUR packagers did include some porting oddities, as they have it NOT run as root
which is viewed as a security risk. They run it as user duplicati, so you can also look in

~duplicati/.config/Duplicati and compare it to ~root/.config/Duplicati files.

I don’t follow. If you mean the job, the job export doesn’t make an SQLite file. It’s JSON.
The job database is SQLite, and that screen will let one reattach it, rather than recreate.

  • Yes, I saw the “single-account-” message.
  • Yes, I updated using the GUI. Poor choice, I understand.
  • ~duplicati/.config/Duplicati contains a single folder “updates” with a readme.txt and a “installation.txt”. See content below.
  • ~root/.config/ => No folder called “duplicati” here.
  • Right, I tried to create a job from a database - that’s why it failed. I don’t think I have exported my main-backup config.



This file is used to track the number of unique installs.
The first line in the file is used as an ID, which is sent to the server when checking for updates.
If the first line is blank, this installation will not be part of the usage statistics.



ExecStart=/usr/bin/mono /opt/duplicati/Duplicati.Server.exe --webservice-port=8200


so user should actually be “duplicati”, not root. Starting with user root probably caused the mix up.

Can you please suggest how I should take it from here?

It can make true situation more confusing, as it’s harder to know what’s in use.
Beyond that, it seems to work, though it looks like the update plan will change.
Maybe the odd AUR user affects updating, but package install might do worse.

It’s Duplicati (if it exists at all). What’s this I see chopped off of the image post?


This is AUR’s special, done because root is riskier, but it’s also handy to get a backup done.
I would have preferred they had not set it up that way. Typically Duplicati users just un-set it.

I’m not a systemd expert, but I think it should have started Duplicati as its unit file is saying to.

About → System info → UserName will say. The Database screen also has path to database.

First figure out the situation.

From the duplicati System info:

APIVersion : 1
PasswordPlaceholder : **********
ServerVersion :
ServerVersionName : -
ServerVersionType : Canary
StartedBy : Server
BaseVersionName :
DefaultUpdateChannel : Canary
DefaultUsageReportLevel : Information
ServerTime : 2024-03-21T11:41:49.952453+01:00
OSType : Linux
DirectorySeparator : /
PathSeparator : :
CaseSensitiveFilesystem : true
MonoVersion : 6.12.0
MachineName : WorkstationII
UserName : duplicati

The chopped of image is the folder path:


This is where my duplicati databases are stored.

That would be entirely right for starting duplicati with /usr/bin/duplicati, but odd for systemd.
Normally that would put them below ~root, and I would have thought AUR use is ~duplicati.

Have you always used systemd startup? Do you recall having hacked on the AUR unit file?
Duplicati’s update would not have changed it though, and System info shows it did get 101.

AUR changes relative to an (I believe) unaltered Duplicati unit file:

-Description=Duplicati web-server
+ExecStart=/usr/bin/mono /opt/duplicati/Duplicati.Server.exe --webservice-port=8200
-ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS

some of which might be based off an old duplicati unit file. I think the priority reduction wasn’t
always there, and I don’t think I like that Duplicati did it. I don’t like AUR User/Group changes.
I’m not sure about their other changes, and I don’t have Arch to test. I might be able to fake it.

I would have thought that would put your databases in ~duplicati not ~dejhost, as you expect.
Something still seems confused about database location. I know I’m still confused. Any idea?

Maybe we can also try:

What user do you want Duplicati to be running as, and where do you want the databases?

Maybe this will jog recall of some previous run history, start history, or setup work to guide.

Default AUR user permits access only to world-readable. If you ran as you, you get yours.
If you backup system administrative things, some of that would probably want run as root.

You might not have a job export, but if need be you can go to the SSH destination to peek.

Direct restore from backup files basically needs SFTP information and any encryption info.
You don’t actually have to finish the restore, but you can browse the files that are available.

I don’t understand how you got your personal home directory job backup databases (the ones
starting with random letters) changed to such recent times. Was there a run just before install?

Be sure you don’t have multiple Duplicati up at once, as that can be confusing. If you want the
systemd started one, you browse to (typically) localhost:8200 directly in your web browser.

If you have systemd and also start one to get a tray icon, then you have started two Duplicati.

There is a –no-hosted-server option if you want to use systemd’s server instead of tray icon’s:

Set this option to not spawn a local service, use if the TrayIcon should connect to a running service.

On a Linux Mint (Ubuntu derivative) system, I installed the AUR unit file you posted, made a
duplicati user and group to satisfy it, made /usr/opt/duplicati as a symlink to /usr/lib/duplicati.

systemctl start has it run as duplicati and give me the First run setup dialog as expected
because even though the system has a ~root/.config/Duplicati and my own .config/Duplicati,
duplicati user is brand new and started thin. When looking at the dialog box, top level shows:

root@LinuxMint21:/home/duplicati/.config/Duplicati# ls -l
total 148
drwxr-xr-x 2 duplicati duplicati   4096 Mar 21 12:44 control_dir_v2
-rw------- 1 duplicati duplicati 139264 Mar 21 12:45 Duplicati-server.sqlite
drwxr-xr-x 2 duplicati duplicati   4096 Mar 21 12:44 updates

The files in root and my Duplicati folders are unchanged. This is also what one would expect.
Continuing by clicking “No, my machine has only a single account” got an Error, somehow, of
“Missing or invalid backup id” which I cleared with an OK so I could see my new jobless page.

-rw------- 1 duplicati duplicati 139264 Mar 21 13:08 Duplicati-server.sqlite

so it did store my setting there, but apparently it didn’t need to add any extra storage to do so.

I’m still not sure what your history is, but there’s what I just tried.

Hello ts678,
thank you for all your input.

Look what I found:

My wiki says that we had similar problems 1,5 years ago:

Seems like uninstalling and reinstalling is the way to go(?)

What user do you want Duplicati to be running as, and where do you want the databases?

I don’t have a preference concerning the user, as long as I have a system tray icon. the folder /home/dejhost/.config/Duplicati/ makes sense to me, but not that important either.

Was there a run just before install?
Some small and local backup-jobs run every 10min. THe ones using sftp run daily.

If you have systemd and also start one to get a tray icon, then you have started two Duplicati.
I definitively had a tray-icon.

(shows seemingly recent server database in /var/lib/duplicati)

Look what I found AUR doing. Are you good at reading their work? I’m just trying to browse it:

path: root/duplicati.env


AUR is forcing databases to go there. It looks like it’s also ~duplicati, but you can ask echo.

Surprising, as user controls what Linux gives access to for backup and restore. Does it matter?

How do you start that? Does it use --no-hosted-server? If not, you might have two Duplicati. There is no --no-hosted-server unless you added it or somehow it got another AUR special. Running sudo ps -ef e | grep -i duplicati will show what you have, user, options, and whether AUR’s DUPLICATI_HOME is actually being used. If environment is too revealing, edit. Doing a separate run without e at the end will also omit the sometimes-quite-long environment.

Similar chase of where-did-things-land. Knowing Duplicati count, users, and DUPLICATI_HOME can indirectly figure that out, as can dates (less so for me, as I don’t know your time at the time).

Direct inspection is possible (carefully), e.g. if Linux permissions allow, you can see what’s in a server database (Duplicati-server.sqlite) by DUPLICATI_HOME=<its folder> duplicati after closing any other Duplicati (tray icon and systemd if you have both, which I’m still asking about).

The server database, if it has some jobs, will let you open Database screen for each to find job databases. As a side note, the one in the image looks too tiny, so probably has no jobs defined.

If you can find your server database and your jobs, it should be safe to click Restore button for some idea of how recent the backups are, and what files are there. Don’t run anything too risky.

I ended up uninstalling duplicati by removing the folders. I kept the databases in /home/dejhost/.config/Duplicati/.

Now I’d like to install duplicati from scratch. Can you recommend a procedure? My goal is the latest stable version with tray-icon.

Not very well. AUR packagers changed a lot and made Duplicati fail by default (as designed).
You’re an Arch user, and I linked to some of their user interactions. Care to be their next one? Alternatively, we can try to feel our way through this.

I trust that we get faster results if you support me here. Once we succeeded, we could put together a guide.
If you agree… where to start?

I suppose start with however you usually install Duplicati Beta from AUR.

Might be worth a forum search to see if there are any bits of an Arch recipe around.
My first forum search hit tripped on AUR gotchas, so then user tried different install.

Above was an invent-it-yourself install to bypass AUR. Might be easier to work with AUR.

Clues currently on the front page for Canary, and same clues probably apply to the Beta.

More clues:

I suspect several of the why-did-my-AUR-update-break-Duplicati have to do with unit files.
I don’t run Linux much, but have had to learn some systemd. Are you good with systemd?

Modify systemd unit file without altering upstream unit file
Modify systemd Config Without Touching Upstream Unit File
How to Change the Default Editor for Editing Unit Files in Linux

might be the thing to do to customize the unit file with lower chance of overwrite on update.

I would usually start with pamac install duplicati-latest, but that package can’t be found.

Following the instructions from the link you provided: I downloaded the debian-package from the duplicati HP and unpacked it. I receive 3 files:

  1. control.tar.gz
  2. data.tar.gz
  3. debian-binary

I used tar -xf to unpack data.tar.gz, and moved the content into the appropriate folders:

[dejhost@WorkstationII tmp]$ sudo cp -rT /home/dejhost/Downloads/tmp/etc/ /etc/
[dejhost@WorkstationII tmp]$ sudo cp -rT /home/dejhost/Downloads/tmp/lib/ /lib/
[dejhost@WorkstationII tmp]$ sudo cp -rT /home/dejhost/Downloads/tmp/usr/ /usr/

Where should the files of control.tar.gz go?

I just commented on the approach as being “invent-it-yourself”. If they didn’t say, I’m not either.
Hand-unpacking Debian packages is not something I do currently, though it might be possible.
There’s probably information somewhere on the Internet.


Same post tries to get you to read AUR information, and systemd information.