Duplicati 2.4.0.0 is the new stable line, superseding 2.3.0.4 and carrying everything from the 2.3.1 betas, and it brings one breaking change worth reading before your updater meets it. The data folder must now have exactly the permissions Duplicati expects, or the program refuses to use it. Older versions quietly locked the folder down when they found it loose; that quiet fixup is gone.
Most installations will not notice: folders on a machine you control generally look the way Duplicati wants already, and the notes say as much themselves. The setups that will notice are the ones that cannot set exact permissions in the first place, a container mount whose ownership the application does not control being the obvious one.
Three ways out are documented. Pass --allow-insecure-datafolder, set DUPLICATI__ALLOW_INSECURE_DATAFOLDER=true where flags are awkward, or place a file named insecure-permissions.txt in the installation folder. Note the location, because the old trick of dropping that file into the data folder no longer works. The same gate covers preload.json, which now loads only from a folder Duplicati trusts or with one of the opt-outs active, and two previously trusted paths — /usr/local/share/Duplicati/preload.json and C:\ProgramData\Duplicati\preload.json — are dropped on the grounds that they cannot be guaranteed locked down.
My read
Treating your own database folder as a security boundary is the correct instinct, and read quickly, the change sounds like a non-event. Then a backup container comes up refusing to start because the volume’s permissions are not what the process expects, and the fix is an environment variable with “insecure” in its name. Read the notes before letting anything update Duplicati unattended, and if your permissions cannot be exact, use the opt-out and move on. That is what it is for.
Source: Duplicati 2.4.0.0 release notes