I think what happens here is the automatic database encryption.
When starting, Duplicati will auto-create a random encryption key and store it in Windows Credential Manager. Since the service runs in a Service context, that credential manager is not accessible to your regular user. When you run ServerUtil it cannot read the encrypted database, and because of this cannot issue a new token.
If you pass the --password parameter, there is no need to access the database.
You can disable database encryption for the service with --disable-db-encryption=true, so the database can be read by ServerUtil.
Alternative is to fuss out the database encryption password, but in that case it is perhaps simpler to just use the regular password.
You can use the secret provider to store the password.
In the terminal, run:
“C:\Program Files\Duplicati 2\Duplicati.CommandLine.SecretTool.exe" set "wincred://" "duplicati-serverutil-password"
This creates the secret “duplicati-serverutil-password” with the value you type.
Then you can run ServerUtil with:
“C:\Program Files\Duplicati 2\Duplicati.CommandLine.ServerUtil.exe” --secret-provider=wincred:// --password=$duplicati-serverutil-password
And it will use the Windows Credential Manager to resolve the password.
(For MacOS, use keychain:// and for Linux use libsecret://, or see docs for more).
If you want to use the ServerUtil without having to type all that stuff each time, you can use a preload.json file with contents like this:
{
"args": {
"serverutil": [
"--secret-provider=wincred://",
"--password=$duplicati-serverutil-password"
]
}
}
If you provide the same arguments on the commandline, these will override the preload, giving you the option to rely on defaults.
The security implication of storing the password in the secret provider is that any process running with the same credentials will have access to the Duplicati server (but not directly the database), but the password is not written in clear on disk.