This release is a beta release inteded to be used for testing.
If no major issue are found with this release, it will be used to create a new stable release.
About this release
This release is a minor bugfix release from the previous beta and fixes a few minor issues discovered during the testing period.
Database version upgrade
No database version upgrades in this version, but the beta releases updates the local database to v17 and the settings database to v9.
The database tool can downgrade to previous versions.
New since last beta
Added an error code check for B2 uploads
Updated ngclient to latest version to fix tooltip issues
Summary of large changes since last stable
New user interface
New datafolder default location for Administrator/root
New backends pCloud, Filen and Filejump.
New backend for SMB to avoid mounting shares
Removed Sia backend and marked Mega as deprecated
Common http options are now applied to backends, and timeout options are renamed
Installer packages are now signed by Duplicati Inc
Remote source support for S3, SSH and SMB
Database is upgraded to v17 for local db, and v9 for settings database
Database upgrade/downgrade tool is provided
New file and folder enumeration logic
Timeouts logic on all backend operations
Improved database validation and repair logic
ServerUtil can output JSON for script integration
Improved support for having Duplicati behind a proxy
Updated throttle logic, all streams share the throttle
Improved repair logic
VSS is automatically on if running on Windows with sufficient privileges
On one of my systems, I’m getting an occasional “Found X faulty index files, repairing now..”
How can we have Duplicati test/repair ALL remote index files? I think I remember seeing instructions on how to do that, but forum search is failing me at the moment.
To remedy existing data, the test method can now be run and only check index files (--full-remote-verification=indexesonly).
By default, any defective index files that are found will be replaced with correct versions, so simply running the test command with a large sample size will fix the backup.
UI Commandline can show that like below. Sample size (e.g. all) is Commandline Argument.
EDIT 1:
so I don’t think any special settings are needed, but if you want a faster run, IndexesOnly avoids downloading the large dblock files. If you want a sooner more certain test, the manual run works.
This is the first beta I’ve tried since the stable release. I noticed that if I exclude hidden files AND system files, hidden files aren’t excluded in the backup.
There is also a small issue with the new GUI. This is what I see when editing the saved backup jobs:
Welcome to the forum @HD1080ide and thanks for the report.
The first problem more generally looks like the exclude-files-attributes option no longer understands its documented comma-separated attributes as of 2.1.0.119_canary_2025-05-29.
Test was an Export As Command-line and --console-log-level=verbose to watch excludes during backup of a folder with files with the different hidden and system files applied with attrib.
2.1.0.118 worked, and then 2.1.0.119 changed a lot of the Options.cs code. Maybe it broke this.
The GUI problem looks like an inability of the new GUI to read back any of the Exclude settings. Although it seems able to set them, next job edit risks losing them, as it doesn’t think they’re set.
While I’m here, I’ll ask dev if it was intended for Details view to be three-line view instead of one:
While this gives more horizontal space in the boxes, it’s harder to read, and the action buttons (which at least don’t risk falling off right edge of the screen) don’t belong to nearest job name. Example is if you wanted to run test 1, would you use button above its name? It’d be wrong.
I have seen something similar before, and it was caused by not having a schedule on one of the backups, and the render code expecting a value. Can you see with DevTools if you get some kind of error that can help trace what is causing this?
I tested on my machine with backup that has no schedule and it looks correct, so perhaps something else is triggering it?
Oddness repeats on repeated use of refresh button. I might experiment with the login options.
From a job schedule view, one backup job has a schedule, and two jobs don’t. I’ll experiment.
Putting a (next year) schedule on the two without a schedule still leaves all mentioned issues.
“Log out” and “Login” is also no help, with or without checking the “Keep me logged in” button.
Firefox has the same visible and network oddities, but a longer list of complaints in its console.
EDIT 1:
Moved Duplicati-server.sqlite to test no jobs. Also tried Chrome. Still three line Details headers.
2.1.1.105_canary_2025-10-10 has three lines, and 2.1.1.104_canary_2025-10-03 has one line.
This was a quick look, not controlling variables, but I don’t recall seeing this in a Canary before.
EDIT 2:
2.1.1.104 in Chrome does do the odd systeminfo refresh systeminfo, but that’s kind of invisible.
Added some clarification of my understanding per my post on tests following the report.
Update covers “what I see when editing the saved backup jobs:”, i.e. the posted image.
That is a probe for systems that are pre-authenticated, like for people running Duplicati behind a proxy with its own Auth mechanism. The first systeminfo call is done to check if we are already authenticated, but we should update this to a new API call that returns 200 and a status message so it does not show up as an error.
It does not explain the rendering issue though
Can you help me with the following steps:
Activate the developer tools
Look at the network tab
Look for “notifications” (you can filter by WebSocket or Socket)
Open the “messages” sub-tab
Look for “Type: backuplist”
Right click and choose “Copy message”
Share that message with me (edit for privacy or send as PM)
