Duplicati 2.0.3.3 beta ate my settings (MacOS)

Support
1

Silly me. I just installed (macOS Sierra) the new beta on top of the old one. That cost me my settings (I should have checked of course, but having settings removed by having an application updated happens so rarely these days that I forgot to check).

I’m using a LaunchDaemon to start the duplicati engine

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.duplicati.server</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Applications/Duplicati.app/Contents/MacOS/duplicati-server</string>
        <string>--webservice-port=8200</string>
    <string>--log-file=/Library/Logs/duplicati_server.log</string>
    <string>--log-level=Information</string>
    <string>--verbose=true</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/Library/Logs/duplicati_out.log</string>
    <key>StandardErrorPath></key>
    <string>/Library/Logs/duplicati_err.log</string>
    <key>Nice</key>
    <integer>20</integer>
</dict>
</plist>

Where again does duplicati store its settings? Is this recoverable?

PS. Has the documentation/manual been updated?

2

By “settings” do you mean backup jobs, global settings, or both?

I know on Windows there has been an issue where customized application shortcuts (such as tray-icon with custom parameters) get overwritten during an install, but I don’t know if that would happen with MacOS plist files…

3

Backup jobs in any case.

4

By default Duplicati will store it’s settings inside the user home directory, which means an OS update should not touch those files.

If Duplicati is running as root the settings will be in /root. This directory is usually not touched in an OS upgrade either, except with Synology who for some unknown reason does whatever it wants to with /root during upgrades.

In either case the OS upgrade should generally not affect the settings and Duplicati upgrades should never affect the settings.

5

It should be noted that:
`. Some of the larger Windows 10 updates have been known to make new C:\Windows directories which can orphan the Duplicati settings folder if running as a service
2. I might be misreading it, but I think the OP issue was a Duplicati update that happened on MacOS Sierra, not an OS update TO MacOS Sierra

@gctwnl, since I’m not sure how the settings got lost in the first place I’m not sure where to suggest looking for them. However, if you do a system search for Duplicati-server.sqlite and dbconfig.json files that should be a start.

If you find more than one set and one has modified dates that end with when you installed the new beta there’s a good chance that your old settings are in those files.

Assuming you find them, you should be able to back up the new files somewhere then copy the “old” ones to the location of the new files and hopefully have your settings back.

Of course, if you DO find multiple copies please let us know what folders they’re in so we can try to make sure it wasn’t the Duplicati update that cause the issue.

6

I must apologise, it seems I fell for the same trap as a while back.

dbconfig.json is nowhere found on my computer. The database is found twice:

-rw-r--r--  1 root  wheel  21504 Apr  5 22:56 /private/var/root/.config/Duplicati/Duplicati-server.sqlite
-rw-r--r--  1 gerben  staff  17408 Apr  2 22:41 /Users/gerben/.config/Duplicati/Duplicati-server.sqlite

The processes running now are:

0   112     1   0  20 20  2444660   1224 -      SNs    ??    0:00.01 /bin/bash /Applications/Duplicati.app/Contents/MacOS/duplicati-server --webservice-port=8200 --log-file=/Library/Logs/duplicati_server.log --log-level=Information --verbose=true
0   246   112   0  20 20  2531468   9136 -      SN     ??    0:00.43 Duplicati Server Duplicati.Server.exe --webservice-port=8200 --log-file=/Library/Logs/duplicati_server.log --log-level=Information --verbose=true
0   385   246   0  20 20  2587716  22244 -      SN     ??    0:04.03 /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono-sgen64 /Applications/Duplicati.app/Contents/Resources/Duplicati.Server.exe --webservice-port=8200 --log-file=/Library/Logs/duplicati_server.log --log-level=Information --verbose=true

And the trap I fell for: I probably started Duplicati when logged in as myself (after having stopped the LaunchDaemons), that starts a webserver that listens on port 8200 but creates a ~/.config/Duplicati which was of course empty. But after a reboot, my LaunchDaemon started again (uses ~root/.config/Duplicati) and when I now connect to port 8200 on localhost, all is well.

7

Glad to hear you got it figured out! And no need to apologize for being tripped up by confusing functionality. :slight_smile:

I’ve gone ahead and flagged your post as the solution in case others bump into the same situation.

8

I have a habit to start an application on macOS once after installing it because it generally is ‘quarantined’ when installed by drag and drop on macOS. That starts a server and uses the starting user’s home directory. Actually, I don’t need to do that as I start it via a LaunchDaemon and that ignores the quarantine.

9

Heh - I do the same thing on Windows, I generally don’t even use the “start application?” option from the installer if it’s offered. I just do it “the old fashioned way” from the Start menu. :slight_smile: