Duplicati can't access file even after access rights have been granted

Support
21

That makes sense. In that case, I have no idea what blocks access to that file.
It’s still strange that you don’t see your mapped drives in the file picker… I’ve tried it with my setup, when I start Duplicati.Server.exe using my own user account, I can see my mapped network drives in the file picker when selecting source files. So somehow your user account seems to be different from the account used to start Duplicati on your computer.

22

Okay, this is embarassing: the solution was there in front of our eyes all along. :flushed: Look at this:

And then this:

https://forum.duplicati.com/uploads/default/original/1X/89e3caca9c2c141ba18afc869829394fffaddb13.png

and this:

image

Notice something?

My default.m3lib is in the media share. But the error came from the together share (apparently I had copied the file there some time ago as a temporary backup and never deleted it. I didn’t realize that and kept looking at the wrong file. I’m sorry for stealing your time with this.

I can say though, that I did learn some stuff, so thanks for that.

So here is what happened when I adjusted the access rights for the file that was actually causing the errors in the first place:

  1. The backup job completed with a fatal error:
8 Dec 2017 21:42: Message
Fatal error
Duplicati.Library.Interface.UserInformationException: Found 1 files that are missing from the remote storage, please run repair
   at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
   at Duplicati.Library.Main.Operation.BackupHandler.PostBackupVerification()
   at Duplicati.Library.Main.Operation.BackupHandler.Run(String[] sources, IFilter filter)
  1. I did not run repair but just ran the backup again. And this time it finished without any error. Phew! :sweat_smile:

However, it looks to me like the “fatal error” was caused by the file not being backed up due to lack of access permission. In other words:

(i) duplicati backs up files but fails to access one of them and issues message (it’s not even a warning, which is also strange).
(ii) when the backup runs again it finds that file missing from the backup archive, thinks the database must be corrupted and asks for a repair.
(iii) when the backup runs yet another time, the file is correctly backed up (due to changed access rights) and there are no more errors.

My question: instead of assuming that there is a problem with the database, shouldn’t duplicati have “remembered” that the file couldn’t be backed up?

My guess is that when a file fails to be backed up, duplicati nonetheless writes it into the database as part of the backup. So this is probably what needs to be changed: only write files into the database if upload succeeded. That might save us a lot of “fatal errors” and unnecessary db repairs…

1 Like
23

It depends on how much data is retrieved. For most failures, Duplicati will just omit it.

I am a bit confused. The error message seems to be related to the backup files (the dblock, dindex and dlist files) but the rest of the post is about a source file?

24

Which error message are you talking about?

By “source file” you mean the default.m3lib?

Reading through my last post, I realize that it may not been clear enough in distinguishing two parts f the post:

  1. saying that large parts of the preceding discussion possibly were unnecessary because I was looking at the wrong file and
  2. describing a new problem that I observed (while looking at the correct file).

The new problem (which can probably be understood without reading the previous discussion) is:

And my interpretation is:

I don’t know how this translates into dblock, dindex and dlist files, I’m basically just saying that duplicati shouldn’t suggest a repair, when it runs just fine without that repair.

25

That is highly peculiar, because the verification code that runs is exactly the same. If you run it more than once, it should fail or succeed the same way all the time, unless the remote data has changed.

I agree that it should not suggest it.

This is the part that confused med, because (i) seems to be related to the source file not being accessible, which is unrelated (?) to the other problem.

I do not understand how the permissions can affect this. In the check, Duplicati just lists the files and does not care if it can read them or not. For the error to occur, the file listing must exclude the file from the list.