The Dropbox API that the Static Channel Backup uses is label as "Deprecated" on Dropbox apps page. It still works and I didn't find a defined date for when the old API will be switched of. But it might make sense to prepare for that.

I am putting this on the v1.7 milestone for now to revisit it for the next release.
I find it kind of odd to have an option like Dropbox in such a great FOSS project. In case you guys would be up for a nicer alternative like encrypted backup by E-Mail, Syncthing, etc.. Let me know.
I absolutely get your point..! Btw, (S/MIME) encrypted email is already available on Raspiblitz..! But as far as I recall it currently does not support attachments...
Having DropBox fading out the old API is a good point for a switch to a better solution. The "Umbrel" people will also provide a backup store for SCB files in the future ... and all you need to access the file from their service automatically in case of a recovery are the seed words. So I think it can make sense to offer a "subscription" in the future for a similar SCB store (replacing DropBox) with an open source backend. This can be a fulmo subscription by default that people then can exchange with their own or other services.
Running v1.6, I just attempted to set up the Dropbox backup with the above caveats, but it's failing. I get a glimpse of error messages, then I'm quickly back to the menu. If someone can point me to how to retrieve the correct logs, I'll post. Thanks.
@shawnyeager the dropbox integration is running fine on my v1.6 release ... but added for retest as part of the v1.6.1 release. If you can get any details on the error message, that would help to get to the bottom of this.
@shawnyeager the dropbox integration is running fine on my v1.6 release ... but added for retest as part of the v1.6.1 release. If you can get any details on the error message, that would help to get to the bottom of this.
@rootzoll Will do. Could you help me with where to pull logs?
Same here, I run a fresh Raspiblitz v1.6 and it never synced to Dropbox. If you tell me what you need, I will try to send it. Also the "Download Backup" in RTL is not working. Code -2 ENOENT. Maybe it belongs together.
Does it help to look into the logs of the background service which is preforming the backup&upload?
sudo journalctl -f -u background -n 10000 | grep -i drop
Make sure to NOT post the output without hiding/masking the credentials!
Also the "Download Backup" in RTL is not working. Code -2 ENOENT
I opened #1570 for that.
sudo journalctl -f -u background -n 10000 | grep -i drop
It shows nothing.
it needs to be a sudo journalctl -u background -b --no-pager -n 10000 | grep -i drop ... the without --no-pager the journalctl never returns
@rootzoll No results.
admin@raspberrypi:~ $ sudo journalctl -u background -b --no-pager -n 10000 | grep -i drop
admin@raspberrypi:~ $
background has no output at all? Can you check if that service is running with sudo systemctl status background
No output at grep.
When I add the access token at Raspi, it says (only for short time): Error in call to Api function. Your app is not permitted to access this endpoint because it does not have the required scope filescontentwrite. The owner of the app can enable...
Than I enabled the files.content.write at Dropbox (also every other .write). When I insert the access token again, now it says:
Dropbox Settings changed...
upload=0
err='unknown'
errMode=#errorsummery missingscope error tag missingscope requiredscope filescontentwrite
Also the GUI at Dropbox changed. It differs to the readme.
Maybe I need to test with a fresh Dropbox Account - will retest for v1.6.2 release.
I got it working ... the script needs small tweak (will upload) AND its important to first set Permission files.content.write and only after that to "generate" the OAuth2 token.
OK merged PR #1735 and test worked with a fresh dropbox account. I keep this issue open a bit for further test reports. But if nothing further pops up this will be part of v1.6.2 release and I am closing issue.
Looks good on testing - closing for v1.6.2 release.
Most helpful comment
Having DropBox fading out the old API is a good point for a switch to a better solution. The "Umbrel" people will also provide a backup store for SCB files in the future ... and all you need to access the file from their service automatically in case of a recovery are the seed words. So I think it can make sense to offer a "subscription" in the future for a similar SCB store (replacing DropBox) with an open source backend. This can be a fulmo subscription by default that people then can exchange with their own or other services.