Failed: Found 10 remote files that are not recorded in local storage

Taomyn · October 13, 2025, 7:48am

I thought I would provide some feedback here because for some months and different versions of the Canary releases I’ve had one server, running Fedora 42, every few days reporting this same issue for one of its backups. However, this backup is using an SMB share on a local Windows 2025 server as its destination, not an offsite one as being reported above.

I waited until this morning for the backups to complete after updating to .105 and this is what it reported:

Failed: Found 10 remote files that are not recorded in local storage. This can be caused by having two backups sharing a destination folder which is not supported. It can also be caused by restoring an old database. If you are certain that only one backup uses the folder and you have the most updated version of the database, you can use repair to delete the unknown files.
Details: Duplicati.Library.Interface.RemoteListVerificationException: Found 10 remote files that are not recorded in local storage. This can be caused by having two backups sharing a destination folder which is not supported. It can also be caused by restoring an old database. If you are certain that only one backup uses the folder and you have the most updated version of the database, you can use repair to delete the unknown files.
   at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(IBackendManager backend, Options options, LocalDatabase database, IBackendWriter log, IEnumerable`1 protectedFiles, IEnumerable`1 strictExcemptFiles, Boolean logErrors, VerifyMode verifyMode, CancellationToken cancellationToken)
   at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(Options options, BackupResults result, IBackendManager backendManager)
   at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(Options options, BackupResults result, IBackendManager backendManager)
   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)

The share is a unique folder dedicated to this server, so there is no sharing with another server. Basically the main share is \LISA\MAGGIE with two backups on this server, one uses \LISA\MAGGIE\DUPLICATI\LOCAL\ for its destination and this backup rarely fails and so far not like this, the second backup uses \LISA\MAGGIE\DUPLICATI\DP. The way I have things scheduled is that when the first backup finishes it starts the second one using an after job script. Basically, the second job just backs up the database of the first job.

If I run a repair then re-run the backup, it usually works but I’ve had times when it needs a second repair. In the case of the above, it worked after a single repair.

My prediction is that it will probably be fine

I just realised that the image shows 3 backups, only two of them use the share and the order is Local (scheduled), Wasabi (scripted), DP (scripted) so there is quite a gap between the two backups using the SMB share.

ts678 · October 14, 2025, 2:54pm

This issue reports “files that are missing from the remote storage”.

Your new report is “files that are not recorded in local storage”

That’s the opposite issue. Would you like me to move the report?

Taomyn · October 15, 2025, 7:28am

Ah yes, wasn’t paying attention so please move it, thanks.

ts678 · October 15, 2025, 11:45am

Is this the typical error, seen on DP backup for several months, with prior backup success?

Prior backup matters because PreBackupVerify happens before backup, so checks prior.

Do you have any logs with the actual file names, so that history of missing can be checked?

In addition to job log, server log at About → Logs → Stored might have them.

Next step is

You can option a log-file, maybe at retry level so that the file uploading will be recorded.

Missing file names might be in About → Logs → Stored.

The job database usually has 30 days of history, but it’s easiest to search using DB browser.

DB bug report is sometimes also an option.

Taomyn · October 15, 2025, 1:15pm

Ok, that’s a lot to go through.

It’s always the same error, just the number of files found changes.

None of the failed jobs are logged with the job, only the repairs are seen for each one:

I’ll look at setting a log option just for this job

No, no filenames are logged under Stored

I’ve generated a bug report for the job database.

ts678 · October 15, 2025, 2:03pm

Might be this serious (IMO) Canary issue:

github.com/duplicati/duplicati

Canary job log not produced upon error since 2.1.0.121

opened 01:56PM - 04 Oct 25 UTC

ts678

- [x] I have searched open and closed issues for duplicates. - [x] I have se…arched the [forum](https://forum.duplicati.com) for related topics. --- ## Environment info - **Duplicati version**: Canary series 2.1.0.121-2.1.1.104 so far. Fortunately Beta seems OK. - **Operating system**: Windows 10 - **Backend**: various ## Description The job log seems to be suppressed if any error occurs. In ngax, one gets the red popup, but no job log to see. Generally the server log gets the error, but is not what the GUI button shows by default, and is not well known. This will cause user frustration and extra support work. When error occurs, log info should exist, with easy path. ``` version popup job server 2.1.0.120 Y Y Y 2.1.0.121 N N Y 2.1.0.122 Y N Y 2.1.1.103 Y N Y 10/03/2025 releases: 2.1.1.104 Y N Y 2.1.2.1 Beta Y Y Y No such host is known. (api.backblazeb2.com:443) No such host is known. (duplicati-oauth-handler.appspot.com:443) ``` Earlier Canary releases generally had a B2 backup sitting in them, so I turned off Wi-Fi for "Verify files". 2.1.1.104 is so new that I made a backup of a file (to set DB), then switched to B2 with a dummy login. I was wishing I had set `number-of-retries=0` like on my usual, because it took awhile to actually fail... 2.1.2.1 Beta was a past-due OneDrive scheduled backup that ran, so I didn't work much to provoke it. I also tested 2.1.1.104 using an invalid source path, changing to a bad drive letter. Usual log loss held. Warning was also tested there (a little bit) using `no-local-blocks`, which is deprecated. Got a job log. Initial forum report [here](https://forum.duplicati.com/t/release-2-1-1-103-canary-2025-09-25/21349/15?u=ts678) had more comment, less detail, and some discussion. The general report was: > Compared to 2.1.2.0_beta_2025-08-20, job logs tend to go missing instead of giving error ## Steps to reproduce 1. Do something that gets an error - **Actual result**: No job log - **Expected result**: Job log ## Screenshots ## Debug log

Then maybe About → Show log → Live will show them even if you just run “Verify files”.

If you can get names, then you can look at file dates to guess what backup wrote them.

Maybe the the bug report will reveal names if you put it somewhere and post a link to it.

github.com/duplicati/duplicati

remote delete failure sets bad DB state, gets "not recorded in local storage" hours later

opened 05:35PM - 04 Oct 25 UTC

ts678

- [x] I have searched open and closed issues for duplicates. - [x] I have se…arched the [forum](https://forum.duplicati.com) for related topics. --- ## Environment info - **Duplicati version**: recent Beta and Canary - **Operating system**: Windows 10 - **Backend**: various ## Description "remote files that are not recorded in local storage." error occurs unexpectedly two or more hours after destination `delete` fails. [Release: 2.1.1.103 (Canary) 2025-09-25](https://forum.duplicati.com/t/release-2-1-1-103-canary-2025-09-25/21349/19?u=ts678) is analysis (after hitting this on a bad network day), steps to reproduce it, and version test. Unfortunately, both 2.0.2.0 Beta and 2.0.2.1 Beta have the problem. 2.1.0.5 Stable looks like it doesn't, so this seems a regression.

comes to mind, but that seems to require a delete failure, and I’m not certain you had it.

SMB has been trouble sometimes. Is this Fedora SMB or CIFS (aka SMB) Destination?

Taomyn · October 16, 2025, 7:42am

The job is running on Fedora server but the destination is a Windows 2025 Server share. I have other Linux machines using the same Windows Server for their destinations.

ts678 · October 16, 2025, 1:23pm

By destinations, I assume you mean Duplicati destinations.

What OS are the other machines running?

On Fedora, do you mount OS SMB, or use Duplicati SMB?

Still awaiting the other information. Nothing to look at so far.

Taomyn · October 16, 2025, 1:49pm

All my Duplicati destinations are either a Windows Server 2025 share or a Wasabi bucket - I don’t use anything else. On my Linux machines, I have some Fedora and Debian, the jobs use the Duplicati SMB as I no longer mount them on the OS as being too unreliable and a p.i.t.a. to set up. This Fedora one is the only one repeatedly failing like this.

As soon as the job fails again I’ll have a log to provide - it worked today but I took a copy of the log so it can be compared to a failed one, in case that helps.

ts678 · October 16, 2025, 3:02pm

Thanks. Sadly, it sounds like OS SMB issues might have been traded for Duplicati SMB issues, although it’s still too early to say. Maybe some dev can speak to Duplicati SMB troubleshooting.