Okan

Almost certainly a limit, and almost certainly not one measured in gigabytes of storage. Uploads failing while downloads and listings keep working is the signature.

The limits that produce this:

1. A daily upload cap. Several providers cap how much you can upload per day, separately from how much you can store. Hit it and uploads are refused until the window rolls over, typically within twenty-four hours. Downloads are unaffected because they are metered differently or not at all. This fits your symptoms exactly and it resolves by itself, which is worth knowing before you spend the evening on it.

2. API rate limits, and this is the one that surprises people. Most sync tools ship with a default set of API credentials shared by every user of that tool. Those credentials have a quota, and it is consumed by everybody in the world using the tool that day. So your uploads can start failing because of other people's activity, with nothing at all having changed on your side.

The fix is to register your own API client with the provider and configure the tool to use it. You then have your own quota, which for a single home server is effectively unlimited. It is a form to fill in on the provider's developer console and a couple of values to paste into your configuration, and it is the single highest-value change you can make to any of these setups.

Do it even if today's problem turns out to be something else. Sharing a quota with the entire internet is a permanent source of mysterious intermittent failures.

3. A per-file or per-request limit — maximum file size, or a limit on operations per second. Failing on the same large file every time points here rather than at a daily cap.

4. Genuine account-level enforcement — a policy flag, a payment problem, a security hold. Rarer, and there is usually a notice in the account's web interface. Worth thirty seconds of looking.

How to tell which, quickly:

• Read the actual error, not the summary. Turn the verbosity up and get the provider's response body. These APIs return specific error identifiers — a rate limit, a quota exceeded, a size limit — and the tool's top-level message flattens all of them into "upload failed". The identifier names the cause outright.
• Try one tiny file by hand. If a single small upload succeeds, you are being throttled rather than blocked, and the answer is pacing. If even one small file fails, it is a cap or an account-level issue.
• Check the provider's status page, which costs nothing and occasionally is the whole answer.

Once you know, the durable fixes are: your own API credentials, a transfer rate limit so you stay under the per-second thresholds, and a backoff on retries. Aggressive retrying against a rate limit makes it worse and can extend how long you are throttled — so a tool configured to hammer a failing endpoint is actively working against you.

The mount propagation point deserves emphasis because the symptom is so misleading.

Everything reports success. The container's logs are clean. You look at the directory from the host or from another container and it is empty, so you assume the mount silently failed and go back to debugging credentials.

Quick check: get a shell inside the container doing the mounting and list the directory there. If the files are visible inside and not outside, it is propagation and nothing else, and you can stop looking at everything upstream of it.

That one test saves a lot of time and it is the first thing I do now.

If you have the option, consider giving each developer their own database rather than their own schema within a shared one.

It makes the isolation total, it makes cleanup trivial — drop the database — and it removes the whole class of problem where a permission granted for convenience quietly makes the separation notional.

Depends what your warehouse charges for and how it handles cross-database queries, so it is not always available. Worth checking before you commit to the schema-prefix approach, because migrating later is more disruptive than choosing now.