Bree

On the design note: do not point a backup program at a mounted remote as if it were a local disk.

Backup tools that expect a real filesystem will do a large number of small operations, and over a network mount that is slow enough to turn a nightly job into a permanent one — and the failure modes on interruption are worse, because a partial write to a remote through a mount is not the same as a partial write to a disk.

Most of these tools can talk to remote storage directly as a backend, without any mount at all. That path is designed for it, handles retries, and is dramatically faster. If you are mounting purely so a backup tool can see the storage, check whether it supports the backend natively first.

The shared-credentials point is the one to act on today. I ran for a year on the tool's defaults, with occasional unexplained failures that I put down to my connection, and they stopped entirely the week I registered my own client.

One caveat worth knowing: a newly registered client is often in a testing state with restrictions, and moving it to a published state can require a review process depending on the provider and the scopes you request. For personal use you can usually stay in the restricted state — you are the only user — but read what the restrictions are, because on some providers a testing client's authorisation expires after a fixed period and your sync stops working weeks later for a completely different reason.

Set a reminder if that applies. It is a nasty one to diagnose from cold.