Cloudsync does a shit job of communicating helpful errors. When setting up a new Backblaze configuration with encryption enabled, this was the error: Nothing in UI tools gave me more information, so I ssh’ed in and blindly searched for logs. Turns out the problem is really obvious when you find the actual error. In /var/log/messages this appeared: 2020-04-30T15:15:54-07:00 disko synoscgi_SYNO.CloudSync_1_create_link[29776]: [ERROR] b2-protocol.cpp(1656): B2Protocol: Failed to download file (https://f001.backblazeb2.com/file/my-backups/%40SynologyCloudSync/cloudsync_encrypt.info), error(403), msg({ "code": "download_cap_exceeded", "message": "Cannot download file, download bandwidth or transaction (Class B) cap exceeded.

When creating a new volume, start with the smallest drive first! When expanding capacity by swapping out drives, start with the smallest drive first! Despite the publicized benefits and ease of management of SHR over classic RAID, a under-highlighted problem is that it still requires new drives to be equal to or greater than existing drives. So when creating a volume with mixed-capacity drives don’t think you can just expand the volume in any order you want.

Wow. Despite the fancy UI fronting pretty serious storage operations beneath, and a whole range of managed packages on offer, I’m amazed there’s no DSM support for ssh keys in 2020. Yes, you can go manually set them up, but sheesh! Offering to enable SSH in the UI, nagging you about having a “strong password”, but not offering to install a key for you is some retro shit.