HI,
I use Duplicati - 2.0.2.19_canary_2018-02-12 with onedrive . I received this error now.
Anyone else with the same problem?
I’ve got the same error. It’s the Oauth server that ran out of money for the day.
@kenkendk mentioned on #1583 that this happened last time because of a spike in users and that he just raised the limit.
I also sent him a message about an hour ago to notify him 
1 Like
I just got a reply from @kenkendk 5 minutes ago that he isn’t able to raise the limit until Saturday evening. However, I believe the daily cap rolls over tonight so the backups should start working again by then.
I don’t think it has happened more than once before, but Kenneth said he’s also going to look into a more long term solution rather than the daily caps.
I’ve got the same error.
I’ve increased the quota, it should be working again.
4 Likes
Could the client store the OAuth info for a longer period of time? gdrive, a CLI tool for Google Drive, stores its token indefinitely, so is there a good reason Duplicati can’t do this? This ongoing dependency on a third party for the proper function of my backup system is not appealing.
It’s not that the token isn’t stored. My automatic jobs, that already had tokens, were also affected and once the service was restored they resumed functioning.
The issue is just that the server is required to validate the token and when it runs out of money it also stops validating tokens. No matter the OAuth implementations it still needs 2 other partys (Duplicatis OAuth server and the remote backend).
I believe the long term plan is to go away from the rented service to a managed server where the only thing to worry about is capacity of the server.
I would love that: less services for me to maintain!
Unfortunately, OAuth does not support such a use-case, and the providers require OAuth logins. The logins create two tokens, a long term, and a short term. You need a short-term token to access the storage. You get the short-term token by presenting the long-term token and the server-side secret to the storage provider.
Since the secret cannot be public, and it requires a server callback url, it cannot work without a server.
You can host your own OAuth server if you like, source code is on Github.
2 Likes
I don’t really know much about OAuth, since I only started reading about it just yesterday, but I came across this link on Googles Developer Pages regarding using installed Apps with OAuth. The key points there to me are:
Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets
and
The main difference is that installed apps must open the system browser and supply a local redirect URI to handle responses from Google’s authorization server.
Would this a viable option, since Duplicati already is running a local webserver anyway which could accept the token response? From reading the documentation, it doesn’t seems like it’s expecting the user to configure any portforwading and even specifically talks about localhost/127.0.0.1 as redirect URL, which clearly wouldn’t be reachable from the internet anyway.
I don’t think so. From what I understand, this functionality (and pretty much all OAuth) is intended to work with “web apps”. You are periodically rejected access, and redirected to the login page. But since Duplicati is meant to run without user interaction, this is not a viable solution, and will not work for those running from the commandline.
Is there an open source version of the duplicati-oauth-handler.appspot.com OAuth server? Could we setup our own OAuth server to use instead? That would provided added control/privacy/security and would also help ease the financial cost on Duplicati.
Source code is here: GitHub - duplicati/oauth-handler: An OAuth handler for running a custom OAuth service on Google App Engine
It’s written specifically for Google app engine but it should be pissible to rewrite it to host somewhere else.
3 Likes
i dont know if this was solved already, but i could not find a solution for this yet. i think RClone solved this issue somehow: Google drive but i dont know if it can be replicated. My understanding of the Oauth Service is not good enough yet.
@kenkendk
Since this morning, I get the Failed to connect: The OAuth service is currently over quota, try again in a few hours for Onedrive v2.
Could you increase the quota again?
I’m not sure that request got through, but before I try another way, how are things going hours later?
Change or remove a spending limit says what sounds like the previous quota was removed in 2021.
There seem to be some other quotas possible, including one done by OAuth server itself seen here.
Is your location (whatever shares an external Internet address) running backups per AuthID rapidly?
It works again now and yesterday three of my hourly backups also ran.
I experienced the issue at home and at work (close by). My provider uses carrier grade NAT and at work also a lot of endusers are combined per public ip.
I’ll observe how it goes in the next couple of days.
That probably makes things worse when a per-IP rate limit is possibly involved. I’m not certain it’s on. Possibly the admin would be willing to raise the limit to support cases like yours of heavy NAT usage.
You can PM me if it starts again.
The quota limit I have seen before, relates to the costs of the servers (dynamic scaling), not to IP-range requests. But there might be something in Google’s load balancers that prevents excessive requests from the same IP.
