`Failed to restore file Could not find file` When Testing Backups

Support
1

Hi,

I am running Duplicati via the linuxserver/duplicati Docker image. The docker-compose file is:

version: "2.1"
services:
  duplicati:
    image: linuxserver/duplicati
    container_name: duplicati
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
    volumes:
      - ./config:/config
      - /:/source
    ports:
      - 8200:8200
    restart: unless-stopped

I have configured a daily backup that saves two directories (user’s home, user is of ID 1000). I can see the backups in the web interface just fine. When I rename some index.html to index.html.bak, select Restore → , choose the index.html in question, then hit “restore” without selecting any other options, the restore process runs for a while, then shows me the following error:

[Error-Duplicati.Library.Main.Operation.RestoreHandler-RestoreFileFailed]: Failed to restore file … Error message was: Could not find file "/source/.../index.html"

The error says the file is missing. Which does not come as a surprise. That’s why I am trying to restore it, am I not? I seem to be misunderstading something here.

Would be great if anyone could point me in the right direction with this one. If you need any more information about my setup or similar, just let me know, will try to provide asap.

2

yes, what you are missing is that Duplicati, being a block based backup system, has a much more complicated process than a simple copy from the backend to the original data. So when the restore process has finished, Duplicati is going through the list of files to restore and comparing the hashes from restored files with the values they are supposed to have (in the local database). If the file has not been restored at all, you will get this error message (else it would display something about a hash mismatch).

So the real problem has occurred earlier. Try to raise error log level and browse the logs to find anything that looks fishy.

I don’t know anything about Docker so I can’t say much about your setup, but I wonder if your process has sufficient rights to write to the place it is supposed to do. Try to restore to a directory where your UID 1000 has full rights (or even better for testing purposes, where anyone has full rights, such as a temp directory)

3

Hi and thanks for your response!

Wasn’t aware of the log-level option until you pointed it out. I have attached the seemingly relevant parts of the verbose log:

    "2022-07-24 16:32:05 +02 - [Warning-Duplicati.Library.Main.Controller-DeprecatedOption]: The option log-level is deprecated: Use the log-file-log-level and console-log-level options instead",
    "2022-07-24 16:32:33 +02 - [Warning-Duplicati.Library.Main.Operation.RestoreHandler-PatchFailed]: Failed to patch file: \"/source/home/.../index.html\", message: Access to the path \"/source/.../athena-landing/index.html\" is denied., message: Access to the path \"/source/home/.../index.html\" is denied.",
    "2022-07-24 16:32:33 +02 - [Warning-Duplicati.Library.Main.Operation.RestoreHandler-MetadataWriteFailed]: Failed to apply metadata to file: \"/source/.../athena-landing/index.html\", message: Could not find file '/source/.../athena-landing/index.html'."

So this kind of confirms your suspicion about permissions. But:

I wonder if your process has sufficient rights to write to the place it is supposed to do.

I confirmed that the container can write in the place it is supposed to by doing a touch /source/.../foo from within the container. The file appears as expected (owner is root, which was not exactly my intention, but is to be expected in Docker context). So permissions should not be an issue at this point.

(NB: I also tried leaving index.html in place but modifying it before trying to restore it from backup. In that case the error is indeed about mismatching hashes. So there generally seems to be a write-permission issue allthough that can’t be the case™?)

4

It’s clear that it’s a permission problem indeed.
As I said I have no clue about Docker, from a quick browsing of the forum’s archives, there is an official Docker image and if you don’t use it, well, you are on your own to make it work :-). From another post:

I gather that other people are using uid=0 instead of 1000, so it could be worth a try.

5

Update: after the problem was narrowed down to permission errors, I asked for support at the linuxserver Discord and someone suggested recreating the container. Which – to my surprise – worked. I guess I must have fiddled with the compose file and forgotten to recreate the container afterwards. Still weird that I was able to create files from within that very container, but oh well…

Thanks for your help @gpatel-fr!