Google drive does not work?


#1

Hi I’m trying to do a local to google drive backup, but when configuring google drive i get a 400 bad request error (when pressing test connection)

I’m using Duplicati - 2.0.3.3_beta_2018-04-02


image

What am I doing wrong?


#2

Try a forward slash. Mine would consistently choke on a backslash, and choked in odd ways with several.

With google drive: Failed to connect: The remote server returned an error: (400) Bad Request. #2292

reported success too. For me, another oddity was that things only worked if Duplicati created the folder…

EDIT: I didn’t get far on figuring out the backslash oddities, but I suspect the access oddity is a scope feature to restrict Duplicati to its own files. This is in general a good thing, but may surprise people doing migrations (as I did to migrate into a subfolder to see what would happen on “Test connection” with various slash styles).

See Here’s the OAuth 2.0 scope information for the Drive API and below, and this post on how I think I set up.


#3

just writing “backup” seems to work but adding “/” as separator results in Connection failed and using “\” results in the error above.

if the sub directory exists or not does not seem to matter.


#4

I don’t see any reports of Google Drive “Connection failed” for Duplicati 2, though GitHub found several for older versions before 2. Reports and source say there might be specifics to the right. Were you given any?

I just tested using an existing AuthID to create backup/aquapi (where neither folder existed before). It gave:
image during the automatic Test connection after creation (took about 25 seconds to fail), but my manual Test connection and backup subsequently ran fine. For your use, you spoke of the sub-directory. What’s the history behind the backup directory? Did Duplicati make it? From my test, one that Duplicati didn’t make should just go unseen (due to scope as mentioned earlier), and another folder of the same name will be created. Odd, but no “Connection failed”. I’m still not sure what that is from (actually I’m still asking for a complete message if one exists). Do you have other applications going to Google Drive that run or not?

If all else fails, maybe instead of subfolders you can clutter the area with names e.g. “backup of aquapi”.


#5

I’m not 100% sure how the directory was created, all i know is that i used it with a older version of duplicati, sadly i don’t know exactly what version as the SD card crashed.

Specifying a non existent directory gives the same error as using a newly created directory.
so currently the only thing that works is backup nothing else.

image


#6

Despite the config gui giving me errors when i press test connection, it seems to work when running a backup script.


#7

My earlier test was in 2.0.3.11, and trying 2.0.3.3 also worked with a folder/subfolder, and Test connection was nice and fast, perhaps 5 seconds. On the other hand, your original report was on 2.0.3.3, so maybe there are some other differences. My tests were on two different machines as well. I’m not ready to call this a regression, however I’m sorry you’re having a poor experience. Is enough working for you to manage? I’m not sure that I’m able to help much more. Especially if you can find a reliable failure, a GitHub issue might get some developers.


#8

I’m using the docker container duplicati/duplicati:latest and it seems somewhat old, but right now its working so i wont complain :slight_smile:.


#9

I’m using the same container - in what way does it seem “old” to you?

I wonder if the safer limited access connection will work if a new auth ID is created. For example, moving to a new machine would require a new token but does Google recognise Duplicati (might be a different version) as the same app and allow access to the existing backup folder?


#10

Answering in reverse order, drive.google.com Settings --> Manage apps just says Duplicati, which I also saw at accounts.google.com where it stated “Duplicati wants to access your Google Account”. This, plus the fact that Duplicati updates don’t break access, makes me think that Google won’t care if Duplicati version moves.

How we get along with OAuth explains some terminology. I’m unclear if quoted “new token” comment refers to “refresh token”, “access token”, or Duplicati’s authid invention. Regardless, I’m able to copy the authid from system to system and retain access. I can even get a new authid and have the old one still work (which might vary depending on destination service – some might void the old refresh token when a new token is issued).

I’m not sure where the testing stands. Trying different single-level folder names would be useful, and trying a two-level folder where Duplicati newly made either the top level or both levels would avoid a re-use question.

Possibly this is some non-access-related bug somewhere that affects the multi-level folder “Test connection”. Finding a reproducible test always helps, otherwise there’s no good way for a developer to do investigations.