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

[fangzhangmnm]

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
rclone/rclone#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).

#	App registration	Consent for this app+user pair granted	GET /me/drive	GET /me/drive/special/approot	PUT .../approot:/x.txt:/content
1	18c496a6-5d86-4ff5-8dd0-67d565480a3e + Account A	months ago	200	200 (childCount 69)	200
2	ebf26c70-b7d7-4e1f-9cb9-4faf4846aa78 + Account A	2026-08-23 18:02 UTC	403	403	403
3	18c496a6-5d86-4ff5-8dd0-67d565480a3e + Account B	2026-08-23 17:56 UTC	403	403	403
4	17172a03-2635-4db0-829a-4cee2543fa81 + Account B	2026-08-23 17:28 UTC	403	403	403
5	ebf26c70-b7d7-4e1f-9cb9-4faf4846aa78 + Account B	2026-08-23 17:14 UTC	403	403	403

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)

UTC	pair	request-id (= client-request-id)
17:56:29	B × 18c496a6...	2d0ce041-3eac-4ad0-8bf1-4d9eea50d667
17:58:51	B × ebf26c70...	af8dec85-a987-41eb-980d-60e72140ebe7
17:58:54	B × ebf26c70...	5d4a692c-f3fb-417d-a9d6-4c759f1570ab
18:02:41	A × ebf26c70...	671766ea-c0a4-40d9-8833-0eb144f75e73
18:02:44	A × ebf26c70...	04b26020-3aeb-45a6-8e6d-8d7661530d3b
18:10:02	B × 18c496a6...	96d09d7e-7cd2-4438-afa2-a4d0072a7e54
18:10:06	B × 18c496a6...	91c59c25-5611-48ac-bedd-ec044b04c61e

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.

[fangzhangmnm]

Update: narrowed down to the scope, and the failure is repairable

I can now reproduce this with one variable, and the failing state can be repaired
permanently — which points at a one-time per-app provisioning step rather than
day-to-day authorization.

Same app registration, same personal Microsoft account, same browser, minutes apart:

UTC	scopes requested	scopes granted (MSAL AuthenticationResult.scopes)	GET /me/drive	GET /me/drive/special/approot	PUT to approot
19:21	Files.ReadWrite.AppFolder offline_access	Files.ReadWrite.AppFolder openid profile	403	403	403
19:23	Files.ReadWrite offline_access	Files.ReadWrite openid profile Files.ReadWrite.AppFolder	200	200	200

The second token also carries Files.ReadWrite.AppFolder and works, so the scope itself is
not being rejected. A token whose drive access rests on Files.ReadWrite.AppFolder alone
is what fails.

Then it stays fixed, even after the broader permission is removed:

UTC	action	result
19:29	re-consent with Files.ReadWrite.AppFolder only, write to approot	200
19:33	revoke Files.ReadWrite at account.live.com/consent/Manage, write again	200

After the revocation the app's granted permissions are only "Have full access to the
application's folder", offline_access and basic profile — verified on the account's consent
management page. App-folder access keeps working.

Reading of this: there appears to be a one-time, per-app provisioning step on the drive.
The Files.ReadWrite.AppFolder consent path currently does not perform it, so every drive call
made with such a token returns 403 accessDenied / serviceReadOnly / "Database Is Read Only".
A broader Files scope does perform it, and once performed it persists. This matches two other
observations: app registrations consented months ago are unaffected, and on a fresh grant the
first calls return 404 itemNotFound on approot, then
503 serviceNotAvailable / itemDisabledDueToPendingProvisioning "User is pending provisioning",
before settling permanently into the 403.

Ruled out: the account, the app registration, the sign-in audience, the authority
(/common and /consumers), the client code, the browser profile, whether the scope was
actually granted, whether Apps/<name> exists (creating it by hand does not help), and
first-party privilege (my own third-party registration works fine with Files.ReadWrite).

Why this matters: apps that deliberately request the least-privileged
Files.ReadWrite.AppFolder permission cannot onboard any new user right now. The only
workaround is to ask every new user for full-drive access once and then drop it, which defeats
the entire purpose of the app-folder permission. Existing users are unaffected, so this is
invisible from a developer's own machine.

Question: is Files.ReadWrite.AppFolder currently expected to work for new consents on
personal OneDrive, and is there a target fix date?

Request IDs for the 403s (all 2026-08-23, personal OneDrive):
fdb10501-2634-4cd6-a9b8-6a2e34a9037e, 671766ea-c0a4-40d9-8833-0eb144f75e73,
96d09d7e-7cd2-4438-afa2-a4d0072a7e54, 2d0ce041-3eac-4ad0-8bf1-4d9eea50d667.