I switched to duplicati and jotta 3 months ago and used the built-in jottacloud connector. But with this change, I’m guessing I have to move to rclone as well.
I’m using the linuxserver/duplicati docker image on a QNAP NAS. And not 100% sure how to get rclone to work - is there by chance anyone who can give a tip on how to get the rclone part configured - it looks like the gui need a rclone config to be working “underneath”
I see that you got jottacloud running with the patch, but in case you would like to run it with rclone instead, I thought I’d give some tips on how I did that. I’m did this on Windows:
Download and unzip rclone. Add the rclone.exe to your Windows PATH (Environment variables).
In case you are running duplicati as a service, I believe it is a good idea to make sure the rclone config ends up in a commonly available folder (and not your user folder - this was the default in my case).
Got an error on the OAuth beta server while trying to repair a database.
Failed to dispose backend instance: Failed to authorize using the OAuth service: Too many request for this key, wait 60 minutes. If the problem persists, try generating a new authid token from: Duplicati Beta OAuth Handler
Is this error related to limitations to the OAuth beta server or Jottacloud? And if it is a limitation to the beta server are there the same limitations to the production server?
The rate limit feature can be enabled or disabled, default disabled:
The configuration template “suggests” enabling it with a value of 4 (requests per hour):
It was obviously enabled on the beta service instance (perhaps with the value 4 from the template), but I have no idea if it is enabled or not in the prod service. I have seen the message myself when testing the beta service, but have no prior experience with the oauth service so don’t know how the prod instance behaves.
Big thanks to @jthall for your valuable input, and for your effort with the beta oauth service!
Please test with latest canary and report any issues. Not all of the steps described previously will now be necessary, but something like this:
Visit https://jottacloud.com/web/secure and log in. Click “Generate” in the “Personal login token” section, and enter your password again. Copy the resultant CLI token.
Open Duplicati, and edit a backup or create a new backup.
Click the “AuthID” link to open a “pop-up” with the official OAuth service showing Jottacloud only. Alternatively just open the main page of the oauth service at https://duplicati-oauth-handler.appspot.com in another tab. Click “Jottacloud login”, paste in the token obtained in the previous step and click “Login”. Copy the resultant AuthID.
Paste in the AuthID you obtained previously in the “AuthID” field
Click test connection and if successful, click through with next and then click save.
Note that if you want to continue to use the same configuration as you have tested the early beta with, you need to remove the “oauth-url” option from the “Advanced options” to make it use the default production oauth handler web service, instead of the beta service that was set up for previous testing of this change. Also remember that you need to generate a completely new CLI token and AuthID, as described above, and replace the existing value in the “AuthId” option.
You need to edit the target url.
Edit your backup → step 2 (target) → click on the three dots → copy target url to clipboard → three dots → import target url → paste url → delete the unsupported options → save
there is an even simpler method:
edit backup → target destination: switch ‘storage type’ to ‘Local Folder or Drive’, remove contents of ‘Username’ and ‘Password’, switch back to storage type ‘Jottacloud’ and continue
Many thanks to all contributors !!! Your hard efforts are very much appreciated!
My tests so far went all fine - backed up and restored small to medium sized batches
Is there a way how to update tokens in all configs?
I’ve about 8-10 (still no sort/order function in duplicati ) individual backup configurations - different timing, different folders,… - that all use the same jottacloud connection.
Some of those cover a lot of data (TBs) and their token expires during the operation - e.g. after all the time without backups, deleting old ones took over an hour, invalidating the token.
Now I can easily generate a new CLI and new OAuth token from it, but I got to replace it manually in each of those backup configurations each time that happens, otherwise, they won’t run on their normal schedule.