This release is a beta release, considered to be stable for general use.
This release is expected to progress to a stable release if no major blockers are found.
Unlike previoius builds, this one has a major change in the build system, so it now runs on .NET8.
The builds are self-contained so Mono or .NET installations are not required to install.
Automatic updating to this version is not supported.
Important changes from last Beta
Updated to .NET8 with OS specific builds
Using Kestrel as the API/UI server
Mandatory password and new authentication scheme for server
Settings database version updated to v8
Backup database updated to v13
New tool to manage a running server
Due to incompatibility with duplicati_client a new tool is included, named Duplicati.CommandLine.ServerUtil.exe/duplicati-server-util.
Summary of changes
Updated to .NET8
Updated to Kestrel/ASP.NET Core
Updated the authentication system
Added support for encrypting database fields
Updated most packages to the latest version, including SQLite
Changed to Avalonia for the TrayIcon
Split into operating system specific packages
Fixed a number of stability issues
Updated backends to work with async
Added a Telegram report destination
Updated WebDAV and FTP backends
Added support for remote control
Improved IPv6 support
Removed 7z compression
Added secret providers
Added a new experimental UI
Added new server-util executable
Added new Agent executable
Removed Tardigrade in favor of Storj
No longer using local blocks for restore by default, and testing more blocks
This will always be a manual process. The reason is that prior to 2.1.0.2, the installation was not aware of how it was installed. Because this information is lacking, newer versions cannot figure out how to update automatically.
Besides this, the change from a common OS-independent package to OS-dependent packages makes it harder to do.
Currently, there is no automatic updater for 2.1.x, so you will only be notified of the update, and have to manually upgrade the installation package.
Uploading file duplicati-b59754efd474c4d36bb048f2dbb9bedf6.dblock.zip.aes (3.87 MB) …
Fatal error => Please call Connect() before trying to read the Capabilities!
The operation Backup has failed with error: One or more errors occurred. (Please call Connect() before trying to read the Capabilities! (Please call Connect() before trying to read the Capabilities!) (One or more errors occurred. (Please call Connect() before trying to read the Capabilities!))) => One or more errors occurred. (Please call Connect() before trying to read the Capabilities! (Please call Connect() before trying to read the Capabilities!) (One or more errors occurred. (Please call Connect() before trying to read the Capabilities!)))
I have tested with SFTPGo and ProFPTD and others reported it working, so I imagine this is something with FluentFTP not being fully compatible with your FTP server.
Can you share what FTP server software you are connecting to?
I will make a patch release if I can reproduce+fix this.
I have a private CA that generates certificates for Duplicati GUI. After upgrade a random installation to 2.1.0.2_beta_2024-11-29 (from 2.0.8.1_beta_2024-05-07) browsers starts showing invalid certificate warning (net::ERR_CERT_AUTHORITY_INVALID). The certificate chain listed in browsers is incomplete (does not include root and intermediate CA’s). The server is running Ubuntu Server 24.04.
I have others linux servers (Ubuntu Server 22.04) running Duplicati (2.0.8.1_beta_2024-05-07) with certificates generated by the same CA and everything works like expected.
What am i doing wrong? How can i debug such cases?
Thanks.
My best guess is that this is related to the slightly convoluted way that Duplicati handles the certificates. The goal is to avoid having the certificates stored on disk, so Duplicati will parse them and store them in the internal database, so they can be used on later launches.
Unfortunately, there is currently no way to force the original certificate to be used, so you would have to proxy the server, which is a bit of a hassle.
But this is the plain message from the server side, without being masked by .NET exception handling.
I don’t have to dig into details, but this seems like the whole TLS part of FTP(S) might be failing / lacking. - Which is not unexpected, I’ve had so many problems with this with different servers and clients over the years. Bad protocol in general FTP(S).
If my assumption is correct, it should be possible to fix it by:
Remove the --use-ssl flag
Add --ftp-encryption-mode=Explicit
The reason why the --use-ssl flag must be removed, is that it will otherwise overwrite the --ftp-encryption-mode flag with Auto.
Is it possible for you to test this change? If I can get confirmation that this is working, it is a one-line code change to get the new FTP client to behave the same as before.
Yet that works, then there are secondary problems, server would prefer TLSv1.3 and we’ll get cipher suite error and so on. - But excluding FTPS/TLS generic protocol issues, it seems that from Duplicati’s part it’s fine. - Unfortunately I don’t have time to deal with this endless mess right now. But maybe some day, it works fine if I drop TLS requirement from both ends.
Someday when it’s quiet, I’ll go through the whole mess in detail. It seems that FTPS and AFTP are also both in parallel supported, with slightly different feature sets. I opted at one point for AFTP because the FTPS at that time had different problems.
This setup requires setting up some test environment, where I can restart both systems repeatedly and change configuration until working combination is found.
After thinking it for a while. I guess I’ll get rid of the FTPS competely, it’s out dated and very problematic protocol as we all (whom uses it) well knows. Let’s go for SFTP and forget this pain.
I updated to this beta from the previous old (mono) beta. Now I have a problem where I can’t backup to my smb share on my home server. I get the error
System.UnauthorizedAccessException: Access to the path ‘/mnt/nasbackup/AlexPC-Fedora/Sync/duplicati-ib171e56ea53c4ce5aae2df6d46359bae.dindex.zip.aes’ is denied.
—> System.IO.IOException: Permission denied
The smb share is mounted using an systemd mount in fstab. I have duplicati running as a systemd service which should be running as root. I can confirm that running as root I can create and modify files on the share.
Was working fine on previous beta.
Both my desktop and my home server run Fedora and I have duplicati gui installed using the RPM.
From the error message it looks like a standard permission issue, but I am guessing that you did not suddenly change permissions. The file:// backend (which I assume you are using) should just use the operation system open(...) call with regular permissions.
The only thing I can think of is that this is somehow a locking issue that is incorrectly reported as a permission issue. Can you try running Duplicati with the environment variable:
DOTNET_SYSTEM_IO_DISABLEFILELOCKING=true
This should slightly change the way the open call is made, and bypass the check for locking.
I find it odd (but maybe not impossible) that it didn’t fail on the dblock that tries to upload first.
There’s not much context on what’s being tried, but you can view job → Show log → Remote.
is what I get on 2.0.8.1 if I have a folder that can be read but not written (because I set it so).
A new name is used for each of the default 5 retries, but files hash shows files are the same.
A better view would be About → Show log → Retry, but you can read 2.1.0.2 logs on 2.0.8.1.
So now instead of a dindex, a dlist is failing. It’s an old one per date, and just barely below the bottom of the screenshot you might see a backup working. I “think” fail is in the test at the end. Below is a live log of a small full backup. You can scroll your view down to see what’s below it.
Dec 10, 2024 7:59 PM: The operation Backup has completed
Dec 10, 2024 7:59 PM: Successfully verified 3 remote files
Dec 10, 2024 7:59 PM: Backend event: Get - Completed: duplicati-b1d9e6a6fbdd74f9cacf2b0d243bdda57.dblock.zip (758 bytes)
Dec 10, 2024 7:59 PM: Backend event: Get - Started: duplicati-b1d9e6a6fbdd74f9cacf2b0d243bdda57.dblock.zip (758 bytes)
Dec 10, 2024 7:59 PM: Backend event: Get - Completed: duplicati-i4b661295f561443c8ade062130dbdd15.dindex.zip (608 bytes)
Dec 10, 2024 7:59 PM: Backend event: Get - Started: duplicati-i4b661295f561443c8ade062130dbdd15.dindex.zip (608 bytes)
Dec 10, 2024 7:59 PM: Backend event: Get - Completed: duplicati-20241211T005919Z.dlist.zip (644 bytes)
Dec 10, 2024 7:59 PM: Backend event: Get - Started: duplicati-20241211T005919Z.dlist.zip (644 bytes)
Dec 10, 2024 7:59 PM: Backend event: List - Completed: (3 bytes)
Dec 10, 2024 7:59 PM: Backend event: List - Started: ()
Dec 10, 2024 7:59 PM: Compacting not required
Dec 10, 2024 7:59 PM: Backend event: Put - Completed: duplicati-20241211T005919Z.dlist.zip (644 bytes)
Dec 10, 2024 7:59 PM: Backend event: Put - Started: duplicati-20241211T005919Z.dlist.zip (644 bytes)
Dec 10, 2024 7:59 PM: Backend event: Put - Completed: duplicati-i4b661295f561443c8ade062130dbdd15.dindex.zip (608 bytes)
Dec 10, 2024 7:59 PM: Backend event: Put - Started: duplicati-i4b661295f561443c8ade062130dbdd15.dindex.zip (608 bytes)
Dec 10, 2024 7:59 PM: Backend event: Put - Completed: duplicati-b1d9e6a6fbdd74f9cacf2b0d243bdda57.dblock.zip (758 bytes)
Dec 10, 2024 7:59 PM: Backend event: Put - Started: duplicati-b1d9e6a6fbdd74f9cacf2b0d243bdda57.dblock.zip (758 bytes)
Dec 10, 2024 7:59 PM: Backend event: List - Completed: ()
Dec 10, 2024 7:59 PM: Backend event: List - Started: ()
Dec 10, 2024 7:59 PM: The operation Backup has started
I don’t know why your read is failing, but earlier you didn’t specifically say a manual read works.
