Auth failure every two weeks or so when using Docker container

I have now twice noticed that backups would just start failing after running fine for about two weeks, e.g. error in backup log:

ERROR STORAGE_CREATE Failed to load the Backblaze B2 storage at b2://ptr727-Duplicacy-Server-1-Backup: Authorization failure

E.g. error in web log:

2019/10/15 00:00:01 Starting schedule Daily at scheduled time 2019-1015 00:00
2019/10/15 00:00:01 Created log file /logs/backup-20191015-000001.log
2019/10/15 00:00:01 Running /home/duplicacy/.duplicacy-web/bin/duplicacy_linux_x64_2.2.3 [-log backup -storage B2-Backup -stats]
2019/10/15 00:00:01 Set current working directory to /cache/localhost/0
2019/10/15 00:00:01 ERROR STORAGE_CREATE Failed to load the Backblaze B2 storage at b2://ptr727-Duplicacy-Server-1-Backup: Authorization failure
2019/10/15 00:00:01 Failed to marshal the configuration: json: error calling MarshalJSON for type main.StorageCredentials: No master password provided
2019/10/15 00:00:01 Failed to save the job result: json: error calling MarshalJSON for type main.StorageCredentials: No master password provided
2019/10/15 00:00:01 Failed to marshal the configuration: json: error calling MarshalJSON for type main.StorageCredentials: No master password provided
2019/10/15 00:00:01 Failed to save the backup job result: json: error calling MarshalJSON for type main.StorageCredentials: No master password provided

On startup there is this error, not sure it is important, as things do work, until the don’t:

2019/10/30 15:19:11 Failed to store the value to the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set

This happens with web in the @saspus docker container, when I restart the container, the backups start working again.

How does the scheduler get the secrets when the master password expires?
Any other ideas?

The master password doesn’t expire. This looks more like that the web GUI was restarted and couldn’t get the master password from keyring. It will start working again once you visit the web GUI and manually enter the master password.

Is that expected?
I can’t keep logging into the web UI to make sure that scheduled backups keep working, is it maybe a problem with the container?

If you can’t make keyring work, you can set the master password in the environment variable DWE_PASSWORD before starting the web GUI, which is of course less secure.

Do you know why the web GUI was restarted?

The server / container will stop and restart as the host is restarted, when config backups are taken, and when the container updates.

Do I understand correctly that after a server / container restart, I must log in at least once for backups to work?

If so, it is not really running as a “server”, and should I then either disable the master password, or set it as an environment variable?

I thought about adding keyring support to the container but that just would shift the issue elsewhere – to unlock the keyring someone would need to input password – and because it’s supposed to be headless – the password would likely need to be passed though environment variable. Might as well use that to pass DWE_PASSWORD itself.

I’m open to ideas – maybe its possible to somehow connect to host keyring instance?

If I have to pass the password as an environment variable I may as well not use a password, since the attack surface is the same.

Is it possible to not have a password such that the secrets are in the clear?