Release: 2.1.0.2 (Beta) 2024-11-29

2.1.0.2_beta_2024-11-29

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
  • Updated blocksize to 1MiB by default
  • Removed RC4 database encryption (auto-decrypt)
2 Likes

One of my backup has “took 00:00:60” for “Last successful backup”.
Is this 60 seconds? Should it be 00:01:00?

Hi Niklas, I think this is a rounding error.
Most likely the backup took 00:00:59.6.. and this is rounded up to 60s which looks weird.

1 Like

Curious if supporting an automatic upgrade from the 2.0.x betas is planned or if this jump will always be a manual process?

1 Like

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.

I have upgraded a few Windows machines, a Linux machine, and my Synology NAS (docker image) to this version. So far everything is working well!

Nice to see a new “beta” release!

2 Likes

Uh oh, this version breaks FTP.

Error message made me laugh and cry:

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.

Hi.

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.

Can you share what FTP server software you are connecting to?

Thanks for reaction, of course.

2024-11-11 FileZilla Server 1.9.4 on Windows with Explicit FTP over TLS

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.

If my guess is correct, then this process strips the intermediate certificates and this causes the verification errors you see. I have registered an issue for investigating/fixing the missing intermediate certificates.

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.

Thanks! I have registered an issue for fixing FTP support here.

2 Likes

I did check the server side logs this morning when it was quiet, and it might be slightly more confusing than I thought.

<Date/Time> Info [Type] Message
<4.12.2024 8:28:04> FTP Session 33362 X.X.X.X [Response] 220-FileZilla Server 1.9.4
<4.12.2024 8:28:04> FTP Session 33362 X.X.X.X [Response] 220 Please visit https://filezilla-project.org/
<4.12.2024 8:28:04> FTP Session 33362 X.X.X.X [Command] USER Backup
<4.12.2024 8:28:04> FTP Session 33362 X.X.X.X [Response] 503 Use AUTH first.
<4.12.2024 8:28:04> FTP Session 33362 X.X.X.X [Command] QUIT

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).

I am trying to piece together exactly how this was working before.
I think the previous FTP client was using Explicit TLS, but the new client is using “Auto”.
This would explain why it tries to send the username before enabling TLS.

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.

1 Like

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.

Great! I have merged the PR, so a point release will include this fix.

To get TLSv1.3, you can add:

--ftp-ssl-protocols=Tls13

:pray:

I have been digging deep to get to the root of this. It turns out it is “as designed”.

EDIT: Nope, it turns out that I was testing with a .pfx file that had root+leaf certificate, but no intermediate certificate. :tired_face:

After fixing the .pfx file, it works as expected with only a little extra code to provide the certificate chain.

1 Like

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.