No, i didnât changed the default file. But i tried to install an older version, because the update asked for a web password which i never set. Do i need to put the encryption key in the default file now?
The web password is a new security enhancement in Duplicati. It is required to have a password for the WebUI now. You can read about how to set/re-set it here:
I am a little confused as to what version you have installed currently? The error message âThe database appears to be encrypted, but no key was specifiedâ is in the latest version of Duplicati v2.0.9.105 and newer).
If you downgraded to, say 2.0.8.1, that error message is not there, but it will instead report a database version mismatch.
Did you perhaps happen to install version 2.0.9.105 which had a faulty encryption mechanism? If that is the case, you need to install 2.0.9.105, disable database encryption, and then upgrade.
The process is described in the release notes for 2.0.9.106:
Note: the database encryption key and the webUI access password are two different passwords. The database encryption key is not mandatory, but the UI password is manadatory.
I had to add a WindowsService password yesterday, so looked to see if that was described.
Nope, although I will concede I didnât just try anyway from an elevated non-SYSTEM admin.
I was guessing it would see the current user, and change the wrong user. The docs say that:
If ServerUtil is launched in a similar environment (i.e., same user, same environment variables) this would allow access in most cases. There are a number of commandline options that can be used to guide ServerUtil in case the environments are not entirely the same.
which is a slightly useful non-specific comfort, but kind of means weâll get support topics on it.
I have to say the port plan may fall in the same boat, and sticky ports make it tough to handle.
So I did it like below, but itâs not really documented nor obvious to someone without expertise:
C:\Program Files\Duplicati 2>Duplicati.CommandLine.ServerUtil change-password --server-datafolder "C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati"
Connecting to http://localhost:8200/...
Please provide the new password: ********
I was going to suggest a friendlier way to aim at a different account, as WindowsService used:
Supported options for the install command: * /localuser Installs the service as a local user.
except it got removed here for some reason (and in both the help text and the code, it appears).
Setting the password on a new service install is bad because Windows logs it in its event log.
EDIT:
DUPLICATI__WEBSERVICE_PASSWORD environment variable is another way thatâs not in the manual, however I havenât seen a good way to do it for a Windows service without making it too revealed.
True. The location of the database for the service is pretty hard to figure out.
Not sure what the real solution is here, as it is difficult (by design) to pass information to the service without it getting logged/stored somewhere.
I guess the WindowsService program could write to the database before starting the service, but that is also fragile, as the service context is not fully known to the installer process (location, database encryption, etc).
I looked it up, and yes it was removed because the Service installer support was missing in .NET core, so the internal function calls that were used in .NET4 are now missing from .NET8. The service install is re-implemented using the Windows native API, and the /localuser option was not implemented.
Without looking at the details of the Windows API, I would imagine it is a simple change to get it back though.
I donât know how big the demand is (probably not zero though). I just had it in mind as an example. Probably a more ordinary problem is setting initial password for a plain SYSTEM Windows service.
Create the Windows Service
suggests PowerShell or sc.exe too. I only checked the latter, but it does allow a choice of account.
On the Linux service side, one security challenge is Initial signin URL in systemd or other logs, however itâs also time-limited, unlike a logged or stored permanent password thatâs too accessible.
Iâm not saying this is an easy thing to solve â being easy on the legit people and hard on attackers.
Didnât got it so i restored the /etc/config dir and after it everything was fine. I used duplicati --webservice-password=xxxxx at the command line and now i have access