Synology Recover Error from B2

[SparcEE]

Just configured Duplicati on my Synology NAS with B2. The job runs fine when it backups up to B2 (I created a small Synology folder with 4 PDFs) as they show up in the B2 folder.

However, when I try and do a test recovery (1 version) I get the following Duplicati error pop-up:

**BadRequest: Invalid HTTP version in Request line. Line: GET /api/v1/backup/1/files/volume1/Shared/Test New Dir/?prefix-only=false&folder-contents=true&time=2019-05-26T19%3A43%3A52-04%3A00&filter=%2Fvolume1%2FShared%2FTest%20New%20Dir%2F HTTP/1.1 **

Is this because it’s not HTTPS? I don’t access the NAS from the WAN, so I hadn’t needed it.

Thoughts?

Thanks,
SparcEE

[kiox]

I’m just having the same issue. Were you able to find a solution?

kiox

Update: Just found out this only happens for file paths which have blanks! Is this a bug?

[drwtsn32]

@kiox

Update: Just found out this only happens for file paths which have blanks! Is this a bug?

Can you clarify - do you mean the path in the B2 bucket has spaces?

[kiox]

No, actually I’m using OneDrive. But I guess it’s not relevant because I get the same error message as the OP.
The blanks are in the original path of the local data.
e.g.
Causes the problem: “/original path/somefile.txt” .
No such problem: “/original_path/somefile.txt”

[drwtsn32]

That’s puzzling because the error message the OP shows is about back end data, which doesn’t have spaces in the filenames. Spaces in the filenames on the source shouldn’t cause any issue.

[kiox]

OP posted a path with blanks as well:

Blockquote %2Fvolume1%2FShared%2FTest%20New%20Dir%2F

%20 is a blank. Blanks don’t matter in file names, but they do in directory names.

[ts678]

@kiox

The blanks are in the original path of the local data.

This might be worth trying:

@naxan

Looked into it - as expected it was an deescaping-like problem with nginx-proxying and can be fixed as follows (at least it “works for me ”):

Also see:

Cannot restore files from directories containing space in name

Operating system: Synology

[drwtsn32]

Good catch - not sure how I missed that. There is definitely a space in the destination path / folder name.

[kiox]

This works! Problem solved… now it would be really nice to not need a manual hack for this

@naxan

Looked into it - as expected it was an deescaping-like problem with nginx-proxying and can be fixed as follows (at least it “works for me ”):

[ts678]

@kiox

now it would be really nice to not need a manual hack for this

That’s Synology code you had to change, right? I suppose you could ask them if they see anything that Duplicati should be doing differently. I’m not enough of an HTTP or proxy expert to follow the issue well.