Failed to list the revisions: Error: Request failed with status code 504

Support
#1

Getting the following error when trying to restore - “Failed to list the revisions: Error: Request failed with status code 504”

Using the saspus Docker container, storage on Google Drive. 5 backup IDs of varying size, same error for all. ID and storage names have underscores and dashes.

Saw a similar issue here with @chabgo.pw - https://forum.duplicacy.com/t/failed-to-list-the-revisions-error-request-failed-with-status-code-405/4437/6

I have no idea how to fix this from the command line though so help would be appreciated. Have tried pulling from a different machine as well, doesn’t throw the error but basically times out.

Failed to list the revisions: Error: Request failed with status code 405
#2

504 indicates a web service issue. Not duplicacy. It may also be issue with duplicacy.com web service that handles token renewals. Or it can be any number of other things.

Try later, or if the issue persists – try creating your own credentials to access GoogleDrive as described in the guide. Doing so has benefit of decoupling from duplicacy.com uptime and getting rid of group api limits. Relevant thread Google Drive, drive.appdata scope, service account impersonate

#3

Thanks, I’ve set up a service account - I have access now, but when trying to access the backup directory for restore (or testing as a new backup location), the logs say the storage hasn’t been initialised?

I was unsure about how to re-add the updated token to an existing storage setup, so I gave the token file the same name as the previous - is this likely to be preventing access or is there another way to update the token file and re-link with the existing storage? @gchen

#4

You may need to add the email address of the service account to the share list of your Google Drive to access the directory there via a service account token file.

Using the same name should be fine. The web GUI passes the path of the token file to the CLI which then read the token in the file so what you did should work. You can’t edit the storage to change the token file path, but you can delete the storage and create a new one with the same storage name to use a different token file.

#5

So I’m not convinced it’s a permissions issue with Google, unless there is a step in the process I might be missing? The existing account has Service Account Admin, Service Account User role permissions, and has also been set to domain-wide delegation (which allows this service account to be authorized to access all users’ data on a G Suite/Workspace domain without manual authorization on their parts).

If I attempt to add a new storage location with the new token, I have access and can see the folder structure of my account, but it won’t let me use an existing backup.

When attemping a restore logs say ‘The storage has not been initialized’, GUI says ‘No backups found on this storage’.

Duplicacy is still connected as an app to drive (the old token method) - do I need to disconnect this perhaps?

I would prefer to avoid having to delete my previous backup and start over due to it’s size, and admittedly wouldn’t be super confident about using Duplicacy again if that were the case.

#6

This never worked for me. It’s unclear how to specify the path to the shared repository in the storage url. Duplicacy otherwise attempts to use service account storage which is limited to 15 or 35GB

#7

Just for the record I’ve since tried again with some of the additional steps in the guide here and still no luck in accessing the existing backup.

I’ve also swapped back the original token - I’m still able to backup, but restore keeps timing out with the same error.

#8

I just realized that this 504 error wasn’t from the CLI. In fact, it was the web GUI that complained about this error because the HTTP request to ask the CLI to list the revisions timed out due to too many revisions. So, this has nothing to do with Google Drive.

What browser are you using? I tested Chrome, Firefox, and Safari which are all able to list 1000 revisions without timeouts.

#9

So seems it had something to do with my setup running the Docker container on a ‘local’ reverse proxy setup using dnsmasq (via Pihole) (see here).

When I pull the instance off that ‘local proxy’ network I can access restores, but strangely it will still work even if I use the Pihole for DNS. Just won’t work on that particular Docker network. Nothing in the Pihole logs showing that its blocking Google requests via the Duplicacy server on any network.

In any case, it takes a long time to pull revisions (10mins) - is this normal? And given I’ve taken the steps to set up service account access as well, is there any way of accessing the existing storage with that? And would there be any benefit to rebuilding a backup repo with that type of access?

#10

I’m not sure if this is your problem, but I have a similar problem using the nginx-proxy reverse proxy docker container. In my case, I’m 99% sure it’s the default timeout that the reverse proxy config uses (I think it’s short…like 15 seconds or something). I ran into this problem with a nextcloud service I also setup on the same server and fixed it with some custom nginx config. I’ll try applying that to the duplicacy-web container and see if it fixes it and share it here if so.

-Johnny