Release: 2.1.0.112 (Canary) 2025-03-26

[ts678]

@marceloduplicati

I will try to replicated FTPS issue soon

@ts678

@Sami_Lehtinen

Even if encryption is disabled, then there’s transaction error:

Is this just on FTP?

was a question to @Sami_Lehtinen. I was thinking FTPS vs. FTP (Use SSL unchecked), however maybe it’s on other storage types. It would be helpful to clarify when it happens.

Symptomatically, the “Transactions are broken” failure is much different than the “TLS is broken” failure, so looking at the FTPS issue is great, but maybe not the entire FTP issue which might not be exclusively an FTP issue, but I hope to hear other destination testing.

To add my part, I’ll say that I haven’t seen a transaction error on B2 or local folder testing.

[Sami_Lehtinen]

@ts678

was a question to @Sami_Lehtinen. I was thinking FTPS vs. FTP (Use SSL unchecked), however maybe it’s on other storage types. It would be helpful to clarify when it happens.

Yeah, now I finally had time to dig in, when configuring new systems and figure out what the problem is… These things require some effort (yeah, I’m sure you guys know, but now everyone maybe), so it’s not always trivial to figuring out what’s causing a problem after update.

It’s clearly related to some security feature which requries the data channels to reuse the same TLS session as the main control connection. After having several painful testing sessions and testing different combinations, I finally figured it out. It does work with FTP and AFTP both, but requires addional setting: --ftp-ssl-protocols=tls12 or --aftp-ssl-protocols=tls12. That seems to enable the TLS session resumption for the (A)FTPS. Phew…

In case anyone else is having the same issue, this is the reason, why FTPS fails to connect with latest versions of Filezilla.

And for sure, this also works with the latest 115 version, so no worries.

Afaik, it only occurs with FTPS. Yet, even if the connectivity is now working with the stuff mentioned above. Some instances still seem to generate this. The backup gets updated as expected, but at the verification step it seems to fail with SQLite error.

---

Backup started at 4/15/2025 2:28:01 PM
Checking remote backup ...
  Listing remote folder ...
Scanning source files ...
  0 files need to be examined (0 bytes)
***redacted***
  Uploading file duplicati-b6865d0728a1847d7b799a5f37dc4187e.dblock.zip.aes (3.90 MiB) ...
  0 files need to be examined (0 bytes)
  Uploading file duplicati-i64a6bea7857644e68e270ebb62de5802.dindex.zip.aes (231.76 KiB) ...
  Uploading file duplicati-20250415T112807Z.dlist.zip.aes (581.17 KiB) ...
Checking remote backup ...
  Listing remote folder ...
Verifying remote backup ...
Remote backup verification completed
  Downloading file duplicati-20250415T112807Z.dlist.zip.aes (581.17 KiB) ...
  Downloading file duplicati-i58baab21fdb34e32993c9f9fee32d1be.dindex.zip.aes (169.70 KiB) ...
  Downloading file duplicati-bb5049c2d3c7d4520abc7a5d1703f4f6e.dblock.zip.aes (31.99 MiB) ...
Fatal error => unknown error
No transaction is active on this connection
Operation: get File: duplicati-20250415T112807Z.dlist.zip.aes Result: {"Size":595117,"Hash":"2Yj6BDSiJtnZrGC0JZQjzFtAuqBpKlBrWHoLK6cL4MY="}
Operation: get File: duplicati-i58baab21fdb34e32993c9f9fee32d1be.dindex.zip.aes Result: {"Size":173773,"Hash":"b2A8pDqgZAx70UwQFYlmo\u002B9qIuJthInY86VwMItdv3M="}
Operation: get File: duplicati-bb5049c2d3c7d4520abc7a5d1703f4f6e.dblock.zip.aes Result: {"Size":33541245,"Hash":"dVtVd4GoeQZK6DEQ870lM9OsXfY6\u002BMQ9UTPvHKLSeaI="}
The operation Backup has failed with error: unknown error
No transaction is active on this connection => unknown error
No transaction is active on this connection

2025-04-15 14:28:47,434: Duplicati error output:

code = Unknown (-1), message = System.Data.SQLite.SQLiteException (0x80004005): unknown error
No transaction is active on this connection
   at System.Data.SQLite.SQLiteTransactionBase.IsValid(Boolean throwError)
   at System.Data.SQLite.SQLiteTransaction.Commit()
   at Duplicati.Library.Main.Database.ReusableTransaction.Commit(String message, Boolean restart)
   at Duplicati.Library.Main.Operation.BackupHandler.RunAsync(String[] sources, IBackendManager backendManager, IFilter filter)
   at Duplicati.Library.Main.Controller.<>c__DisplayClass22_0.<<Backup>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Duplicati.Library.Utility.Utility.Await(Task task)
   at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Func`3 method)
   at Duplicati.Library.Main.Controller.Backup(String[] inputsources, IFilter filter)
   at Duplicati.CommandLine.Commands.Backup(TextWriter outwriter, Action`1 setup, List`1 args, Dictionary`2 options, IFilter filter)
   at Duplicati.CommandLine.Program.ParseCommandLine(TextWriter outwriter, Action`1 setup, Boolean& verboseErrors, String[] args)
   at Duplicati.CommandLine.Program.RunCommandLine(TextWriter outwriter, TextWriter errwriter, Action`1 setup, String[] args)

[marceloduplicati]

@Sami_Lehtinen Thanks for the SFTP update. I will still replicate the scenario and see if I can add a warning with the parameter suggestion when error is detected.

[Sami_Lehtinen]

If there’s any log or anything else (except the backup data / credentials). I’m happy to provide it. If’s suspected it could have something to do with the local Duplicati database, I can zap it and restart that backup set. But generally that should be a bad solution. Backing up works perfect, it’s just verification which fails strangely.

I also experimented with alternate setup, for an environment where I would need to use VSS (WIndows Server) and got AlphaVSS DLL (missing?) error? There are no up to date open issues on GitHub about this… So is it know issue, or nobody’s just using it? Did I just mess up something? - I can dig the complete error from logs, or reproduce it tomorrow, if necessary. I’ve got environments where VSS would be now useful.

I did clean setup with latest canary on the system, and for some reason, I’m not getting AlphaVSS DLL error anymore. So that’s awesome. Don’t know what the issue actually was. But now it’s all good and working. - My bad, now it was reset to auto, which of course “works” but doesn’t work as desired.

On other server I’ll get this error:

Failed to initialize windows snapshot instance => Could not load file or assembly 'C:\Program Files\Duplicati 2\AlphaVSS.x64.dll'. The specified module could not be found.
Fatal error => Failed to create a snapshot: Could not load file or assembly 'C:\Program Files\Duplicati 2\AlphaVSS.x64.dll'. The specified module could not be found.

That error message is (probably) just misleading. It’s most likely related to the user rights / system role / file system settings. Yet it says “could not be found”. I’ve checked file is in the directory and readable by the user. - Messages like that could mislead users and make trouble shooting harder. ( I’ve got similar issues with other platforms and programs every day ).

No error: $null = Get-Content "C:\Program Files\Duplicati 2\AlphaVSS.x64.dll"

---

Based on some analysis, I think it should work without changes. But probably I need to replace some files. Just wondering if correct files are shipped with setup?

System.IO.FileNotFoundException: Could not load file or assembly 'C:\Program Files\Duplicati 2\AlphaVSS.x64.dll'. The specified module could not be found.
File name: 'C:\Program Files\Duplicati 2\AlphaVSS.x64.dll'
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at Alphaleonis.Win32.Vss.VssFactoryProvider.DefaultVssAssemblyResolver.LoadAssembly(AssemblyName assemblyName)
   at Alphaleonis.Win32.Vss.VssFactoryProvider.LoadAssembly()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at Alphaleonis.Win32.Vss.VssFactoryProvider.GetVssFactory()
   at Duplicati.Library.Snapshots.Windows.AlphaVssBackup.CreateVssBackupComponents()
   at Duplicati.Library.Snapshots.Windows.AlphaVssBackup.GetVssBackupComponents()
   at Duplicati.Library.Snapshots.Windows.AlphaVssBackup.Create()
   at Duplicati.Library.Snapshots.Windows.SnapshotManager..ctor(SnapshotProvider provider)
   at Duplicati.Library.Snapshots.WindowsSnapshot..ctor(IEnumerable`1 sources, IDictionary`2 options, Boolean followSymlinks)
2025-04-16 10:17:01 +03 - [Information-Duplicati.Library.Main.Operation.BackupHandler-SnapshotFailed]: Failed to create a snapshot: Could not load file or assembly 'C:\Program Files\Duplicati 2\AlphaVSS.x64.dll'. The specified module could not be found.

Ref:

C:\Program Files\Duplicati 2\AlphaVSS.x64.dll could not load

This morning I am getting this error on one of our PCs. “Could not load file or assembly ‘C:\Program Files\Duplicati 2\AlphaVSS.x64.dll’. The specified module could not be found.” The file exists. Coincidentally (probably not), the computer also installed Windows 11 KB5050009 (CU for Win11 24h2) and KB5049622 (CU for .net). I am running 2.1.0.2_beta_2024-11-29. I have tried doing a repair install, uninstall and reinstall and no difference. The error comes up when I try to run a backup.

Hyper-V error "Could not load file or assembly 'AlphaVSS.Common"

Welcome to the forum @esackbauer Yes. Is that a problem? The release noted changes in 2.0.0 don’t look particularly essential and didn’t come out early enough (December 2019) to be adequately proven in time for Beta launch in January. What was happening before that? I don’t think Duplicati is intended to have people upgrading its parts.

This seems to be the best tread about the problem, if I can’t resolve it trivially. I’ll continue here:

Missing AlphaVSS.x64.dll error on clean install

Unfortunately, after these actions I see same error. The alphavss folder should contain 3 files: AlphaVSS.Common.dll, AlphaVSS.x64.dll and AlphaVSS.x86.dll. - Yes and root folder of D2 contain: AlphaVSS.Common.dll

In all cases it started to work by replacing files. I’ll try the same.

Continued here: Missing AlphaVSS.x64.dll error on clean install - #23 by Sami_Lehtinen

[kenkendk]

@Sami_Lehtinen

If there’s any log or anything else (except the backup data / credentials). I’m happy to provide it. If’s suspected it could have something to do with the local Duplicati database, I can zap it and restart that backup set. But generally that should be a bad solution. Backing up works perfect, it’s just verification which fails strangely.

I think it is related to something else. The error message indicates that the transaction is somehow not active. I have merged one potential fix for it, but given that I have not been able to reproduce, I cannot know if it fixed the situation you see.

The part of the code that fails (Duplicati.Library.Main.Operation.BackupHandler.RunAsync) is used in pretty much every single test we run on CI for every commit, and still I have not seen it there. It could make sense if there was somehow a different version of SQLite on the machine that got loaded, but I cannot imagine why/how this could happen.

@Sami_Lehtinen

On other server I’ll get this error:

Failed to initialize windows snapshot instance => Could not load file or assembly 'C:\Program Files\Duplicati 2\AlphaVSS.x64.dll'. The specified module could not be found.
Fatal error => Failed to create a snapshot: Could not load file or assembly 'C:\Program Files\Duplicati 2\AlphaVSS.x64.dll'. The specified module could not be found.

That error message is (probably) just misleading. It’s most likely related to the user rights / system role / file system settings. Yet it says “could not be found”.

It is usually because some dependency cannot be found. So the error message is “correct” in the sense that “some file” could not be found. But misleading because it looks like the top-level file is the missing one.
You can use something like DependencyWalker to open the file and see if I can show what files are actually missing.

@Sami_Lehtinen

Continued here

Summarizing for anyone reading this later:

The vcredist package is missing, and it was solved by using --snapshot-provider=wmic to use the new WMIC-based snapshot creation method.

[Sami_Lehtinen]

With 116 version the database transactions when verifying are again working. That’s good as well. I don’t know what the problem was, but at least it doesn’t exist anymore. At least with fresh and new setups.

[kenkendk]

I looked at my notes, and I can see I was wrong: we do see the transaction issue rarely in CI tests.

After I wrote that I have seen the error twice. Each time, re-running the CI test with no changes “fixes” the problem.

I have made some updates to .117 that makes it less likely to happen, but I still do not have the root cause identified. I am thinking this is some pointer weirdness where an object is free’d but the pointer is still used for a transaction. When trying to access it random things happen.

I have also seen a message similar to “Invalid API usage” around the same area.

Still tracking it, but it is not easy to find.