Thanks. Wasn’t aware that I had to create another remote “local”. 
In addition I had to copy the rclone config file to the desired location on my Qnap. I’m sure there is an eaiser way, but now it works.
So I am happy until duplicati will (hopefully) get fixed.
Does the “local copy” mean, I’ve to get an extra 8TB HDD to store duplicati files, that then get backuped to Jottacloud?
It doesn’t. From what I can tell Jottacloud uses the local storage as a staging area so that it can upload one archive while preparing another, so it will never need more than 2x the maximum archive size of temporary storage.
I’m just guessing though. It doesn’t seem to fill my HDD up even when doing massive backups.
There’s no prior mention of “local copy”. Rclone “local” just refers to the local system, not specific files.
shows how an upload is done, and I think (like most uploads), upload comes from the temporary folder. Downloads are similar. The difference is that rclone does one-by-one transfers because old code can’t.
Exactly, and this isn’t just Jottacloud or Rclone, but pretty much anything. These options configure:
asynchronous-upload-limit
asynchronous-upload-folder
While you might need more than 2x Option screen 5 Remote volume size in the temporary folder, if space was enough for Jottacloud, it will most likely be fine for Rclone-as-workaround-for-Jottacloud…
This issue is believed to be resolved after applying the following workaround. Once the PRs get merged, you won’t need any special build instructions.
Please try the following instructions and let us know if you run into any problems.
Users should perform the following steps:
Do I need to build Duplicati by myself?
Or you can wait for the next Canary release.
Well… Before the Duplicati PR can be merged the related oauth service PR must be merged. And who knows when that will happen. Also, the complexity with the oauth service makes it a bit cumbersome to test properly, so it would have been very good if someone would test the Duplicati PR/branch against the oauth service beta deployed from the other PR/branch, as described above.
Good point about looking for additional people willing/able to test before the PR merge!
How do we build it with that branch PR? Suppose no existing DEV environment on Win10 PC.
How do we run it in parallel with existing duplicati (installed as a System service), so it doesn’t jeopardize “the production”?
Feedback goes to Jottacloud removed basic authentication, Duplicati can no longer connect · Issue #4697 · duplicati/duplicati · GitHub I guess.
The big missing piece would then be Visual Studio. A clean solution could be to use a vm from Microsoft with Visual Studio based dev env preinstalled: Download a Windows virtual machine - Windows app development. I think this should include the correct .NET Framework targeting pack etc necessary to build Duplicati.
Then you need the source code from the PR branch: https://github.com/albertony/duplicati/tree/jottacloud_oauth. Either git clone, or download as zip from github web gui.
Then open Duplicati.sln in visual studio, build and run.
If you build and run the Debug configuration I think it it will use a local clean database separate from any other installations, and with Release you can achieve the same by running it with command line argument --portable-mode.
Make sure you set the OAuth URL so it runs against the beta oauth deploy instead of prod, as described in a previous comment.
I may be missing some details here, so others are welcome to correct me or fill in…
I just noticed that if the specified destination path does not exist, and you accepts Duplicati to create it, this fails because this specific request seem to go via prod oauth service even if a different one is configured. So for this test you must ensure the destination path exists, create it from Jottacloud’s web gui or something. And this is an issue unrelated to the Jottacloud backend or this pr.
(I just pushed some updates to the Duplicati pr branch, improving the backend config ui for Jottacloud so that it permanently shows the authid, not just buried in the advanced, identical to how box.com, dropbox.com and others look like).
yes, you need to pull the PR into your tree, then build it.
git clone https://gitub.com/Duplicati/Duplicati
cd Duplicati
git pull origin pull/4699/merge
Then rebuild it however you would normally build a Duplicati binary.
I tried to get the machine up, but with VirtualBox on my Win10 Home (so no Hyper-V) machine, even after disabling the Hypervirtualization in windows features, I cannot get it running :\
It ends with a black window with gray dots of the windows logo several times on the screen, consuming the CPU but not reacting to anything. Dunno where to report it, as there’s its OT…
June 1st is approaching terribly fast. Is there any chance that this issue will be resolved in the next two weeks? 
Probably greater than zero, but I would guess it rather low. Too many pieces. Too few volunteers.
I’m not even sure how well the pieces are working. Who besides the developers use test server?
Note that this is not a Duplicati operated server, but a community-run effort (despite server URL).
It’s great to see the community help, but how far to go? Would people install a community build?
There are risks to getting off the official path, but it’s not clear what to do until official can happen.
It sounded like the rclone option was stable, or did it break for someone?. Might need to use that.
I have been using rclone since the problem surfaced and it’s been okay. Probably not as efficient, but it gets the job done.
Thanks for the confirmation that it works well. I’ve now edited all my backups to use Jottacloud through rclone and it worked without a hitch. 
So they re-disabled the authentication as the extra time expired.