Personal OneDrive: newly consented apps get 403 accessDenied / serviceReadOnly ("Database Is Read Only") on ALL drive endpoints, while an app consented months ago works for the same user at the same moment

Summary

On personal Microsoft accounts (OneDrive Personal), any app registration whose delegated consent was granted today receives 403 accessDenied / innerError serviceReadOnly / message "Database Is Read Only" on every drive endpoint, including GET /me/drive.

At the same moment, on the same machine, with the same user, the same scopes and the same code, an app registration that the user consented to months ago returns 200 and can read and write normally.

This looks related to the reports in https://github.com/rclone/rclone/issues/9794 and https://learn.microsoft.com/en-us/answers/questions/5982450/ but is more severe: in those reports only the plural GET /me/drives fails while the singular GET /me/drive succeeds. In our case the singular endpoint fails too, and only for recently consented app+user pairs.

Environment

• Account type: personal Microsoft account (OneDrive Personal, driveType: personal)
• Delegated scopes: Files.ReadWrite.AppFolder, offline_access
• Auth: MSAL.js v3.27.0, SPA redirect flow, authority /common and /consumers (both reproduce)
• App registrations: SPA platform, both AzureADandPersonalMicrosoftAccount and PersonalMicrosoftAccount audiences reproduce
• Tenant the registrations live in: c1fef054-68f1-48db-9097-61acbe59b8ac
• Date of all observations: 2026-08-23, 17:00-18:10 UTC

Reproduction

Two personal Microsoft accounts:

• Account A — long-established personal account, consented to app 18c496a6-5d86-4ff5-8dd0-67d565480a3e several months ago.
• Account B — personal account created 2026-08-23. Its OneDrive works normally in the web UI (verified with a manual file upload/download round trip).

Rows 1 and 2 are six minutes apart, same user, same browser, same code path, same scopes. Rows 1 and 3 are the same app registration with two different users.

Error body (identical for every 403):

{"error":{"code":"accessDenied","message":"Database Is Read Only",
"innerError":{"code":"serviceReadOnly","date":"2026-08-23T18:02:41",
"request-id":"671766ea-c0a4-40d9-8833-0eb144f75e73",
"client-request-id":"671766ea-c0a4-40d9-8833-0eb144f75e73"}}}

Earlier attempts on the same pair (17:14-17:15 UTC) returned a different error first, which suggests a provisioning state machine that never completes:

{"error":{"code":"serviceNotAvailable","message":"User is pending provisioning",
"innerError":{"code":"itemDisabledDueToPendingProvisioning", ...}}}

and, on the very first call, 404 itemNotFound for the app folder.

What we ruled out

• Not the account. Account A gets 200 on one app registration and 403 on another, minutes apart.
• Not the app registration. Registration 18c496a6... returns 200 for Account A and 403 for Account B.
• Not the sign-in audience. Both AzureADandPersonalMicrosoftAccount and PersonalMicrosoftAccount reproduce.
• Not the authority. /common and /consumers both reproduce.
• Not the scope. Identical scopes on the working and failing calls. GET /me/drive is demonstrably within Files.ReadWrite.AppFolder here — the working pair returns 200 for it.
• Not the client code. The same page, same build, same MSAL version produces 200 and 403 depending only on which app registration is selected.
• Not a missing app folder. Pre-creating Apps/<app display name> manually in the OneDrive web UI does not help — the 403 happens on GET /me/drive too, upstream of any folder.
• Not quota or account state. The working pair reports quota.state: normal, ~19% used.
• Not the OneDrive service overall. The web UI works normally for both accounts.

The only variable that tracks the outcome is how recently consent was granted for that specific app + user pair.

Request IDs (all serviceReadOnly 403s)

itemDisabledDueToPendingProvisioning 503s, same day 17:14-17:15 UTC: 0b1dae7c-1bb6-4342-9350-b15b93796e44, b8002bb7-caab-4be4-86dd-9760fae7f637, d94f7631-6482-4948-85f2-c7fbfb54fa6e.

Questions

1. Is this the same service-side incident as rclone#9794 / Q&A 5982450, with a larger blast radius, or a separate issue?
2. Is the "pending provisioning" state for a new app+user pair expected to resolve on its own, and if so within what time? (Four hours was not enough.)
3. Is there anything an app can do to trigger or wait for that provisioning correctly, other than retrying?

This currently makes OneDrive sync unusable for every new user of an app, while existing users are unaffected — which is why it is hard to notice from the developer's own machine.