I run Duplicati in a docker container, which works wonderfully BTW, but I am having an issue with making a change to how I have it setup. I was able to figure out how to run the container with https enabled, as I described in this post.
I am changing the way I have things setup to use the jwilder/nginx-proxy and the JrCs/docker-letsencrypt-nginx-proxy-companion to provide SSL now though, but Duplicati doesn’t seem to want to let go of the SSL cert that I gave it. I’ve tried removing the volume with the cert from the docker run command as well as removing everything ssl related from the command. But when the container runs, it still runs with https only which doesn’t work with the nginx-proxy container.
Could the database somehow be holding onto the cert? If so how can I get rid of it so that I can use straight http again?
I don’t know, but you can move the old Duplicati-server.sqlite aside temporarily to test with a new one. Checking (perhaps with ps -F) invocation options to your Duplicati server or tray icon is another test.
I did what you suggested and started my container with the Duplicati-server.sqlite renamed so that it would create a new one and confirmed that allowed the Nginx proxy after adding a hostname. So how do I go about removing the ssl cert from the database? Will I have to do it manually with sql commands or is there another way?
I wouldn’t think you’d need to type SQL commands. Really, I’d hope Duplicati could do it, but I’m not set up to test it. Possibly a first step is to install an SQLite browser such as DB Browser for SQLite then look for the database storage of that. There are definitely options kept in the Option table, but I’d have hoped they are controlled by the usual option UI, including the global ones (which I think are the ones with BackupID of -1) controlled by Settings on the Duplicati home screen. It would be worth going to your job using either Commandline to see if there are any certificate-related options there, then track down their source to fix it.
I’m not sure it makes sense to have the server HTTP options per-job, but I’m not sure where they’re kept, beyond the possibility that they’re passed in on each server start (but I guess your DB test ruled that out).
$ duplicati-server help
Supported commandline arguments:
--tempdir: This option can be used to supply an alternative folder for temporary storage. By default the system default temporary folder is used. Note that also SQLite will put temporary files in this temporary folder.
--help: Displays this help
--parameters-file: This option can be used to store some or all of the options given to the commandline client. The file must be a plain text file, UTF-8 encoding is preferred. Each line in the file should be of the format --option=value. The special options --source and --target can be used to override the localpath and the remote destination uri, respectively. The options in this file take precedence over the options provided on the commandline. You cannot specify filters in both the file and on the commandline. Instead, you can use the special --replace-filter, --append-filter, or --prepend-filter options to specify filters inside the parameter file. Each filter must be prefixed with either a + or a -, and multiple filters must be joined with :
--unencrypted-database: Disables database encryption
--portable-mode: Activates portable mode where the database is placed below the program executable
--log-file: Outputs log information to the file given
--log-level: Determines the amount of information written in the log file
--webservice-webroot: The path to the folder where the static files for the webserver is present. The folder must be located beneath the installation folder
--webservice-port: The port the webserver listens on. Multiple values may be supplied with a comma in between.
--webservice-sslcertificatefile: The certificate and key file in PKCS #12 format the webserver use for SSL. Only RSA/DSA keys are supported.
--webservice-sslcertificatepassword: The password for decryption of certificate PKCS #12 file.
--webservice-interface: The interface the webserver listens on. The special values "*" and "any" means any interface. The special value "loopback" means the loopback adapter.
--webservice-password: The password required to access the webserver. This option is saved so you do not need to set it on each run. Setting an empty value disables the password.
--webservice-allowed-hostnames: The hostnames that are accepted, separated with semicolons. If any of the hostnames are "*", all hostnames are allowed and the hostname checking is disabled.
--ping-pong-keepalive: When running as a server, the service daemon must verify that the process is responding. If this option is enabled, the server reads stdin and writes a reply to each line read
--log-retention: Set the time after which log data will be purged from the database.
--server-datafolder: Duplicati needs to store a small database with all settings. Use this option to choose where the settings are stored. This option can also be set with the environment variable DUPLICATI_HOME.
$
I’d guess --webservice-ssl* options are relevant, but I haven’t run them (even without Docker) so can’t say.
For anyone else that runs into this issue, I was able to use DB Browser for SQLite which @ts678 suggested, downloaded my Duplicati-server.sqlite file and remove the ssl certificate value from the options table. I then stopped the Duplicati service, moved the modified database in, and restarted the service and all is well.