OneDrive personal: upload session PUT and file downloads return 401 BadContextToken since Nov 12, 2026

Douglas McClelland 0 Reputation points
2026-11-13T11:11:58.8433333+00:00

Since about 21:45 UTC on Nov 12, 2026, my personal (MSA) OneDrive rejects file content requests made through Microsoft Graph. Sign-in, token refresh, listing children, item metadata, deletes, createUploadSession and simple PUT uploads to graph.microsoft.com all succeed with the same token.

Failing:

  1. PUT of file bytes to the uploadUrl returned by createUploadSession (my.microsoftpersonalcontent.com) → 401, empty body, with headers: WWW-Authenticate: Wlid1.1 realm="WindowsLive", fault="BadContextToken", policy="MBI_SSL" X-Ms-Invokeapp: 1; RequireReadOnly No Authorization header is sent on the PUT, per the docs.
  2. Since about 01:30 UTC Nov 13, GET of file content (the download URL on my.microsoftpersonalcontent.com) → 401.

It is still failing as of Nov 13. The OneDrive desktop client on the same account syncs normally. Client: rclone 1.75.2 and 1.76.0 on Ubuntu; both fail identically. The same failure is reported here: home-assistant/core#192379

Is this a known service-side regression from the Nov 12 incident, and why would the content endpoint treat the account as RequireReadOnly?

This is a OneDrive - Personal account, not a business account.

Microsoft Security | Microsoft Graph

1 answer

Sort by: Most helpful
  1. AI answer

    2026-11-13T11:13:03.4166667+00:00

    Use --onedrive-upload-cutoff 250M as a temporary rclone workaround for files below 250 MiB; downloads and files at or above that threshold must wait for Microsoft’s OneDrive Personal content endpoint to recover.

    Assessment

    The available evidence is strongly consistent with a Microsoft-side regression affecting preauthenticated OneDrive Personal URLs:

    • Microsoft’s public status page reports a broader service degradation affecting Microsoft 365 and consumer products, including some Graph scenarios. It does not, however, publicly identify my.microsoftpersonalcontent.com, BadContextToken, or this exact OneDrive Personal failure signature.^1^
    • The rclone maintainer reproduced the issue on a OneDrive Personal test account: upload PUTs, session status/cancellation requests, and downloads through my.microsoftpersonalcontent.com failed, while listing and single-part Graph uploads continued to work. The matching rclone issue remains the best case-specific incident tracker.^2^
    • A separate Home Assistant report shows the same sequence—successful createUploadSession, followed by 401 on the first upload fragment—and its maintainer associated it with the current Microsoft outage.^3^
    • A previous, closely matching upload-session outage was confirmed in Microsoft Q&A as a global outage, although that report concerned June 2025 and cannot itself confirm the November 2026 incident.^4^

    This pattern does not point to an expired Graph token or an rclone authentication failure: Graph metadata operations work, session creation succeeds, two rclone versions fail identically, and the actual failures occur on the separate preauthenticated content host.

    Temporary upload workaround

    For files smaller than 250 MiB, force rclone to use the simple Graph upload path:

    rclone copy /path/to/file onedrive:/destination \
      --onedrive-upload-cutoff 250M
    

    For a configured remote, the equivalent setting is:

    [onedrive]
    upload_cutoff = 250M
    

    This avoids createUploadSession and its failing content-host PUT. It does not help files at or above 250 MiB, which still require chunked upload in the reproduced rclone scenario.^2^

    Do not add an Authorization header to the upload URL. Microsoft documents that the returned URL is preauthenticated and that adding the Bearer [Token] to fragment PUTs can itself produce 401 Unauthorized.^5^ Your trace already follows this requirement, so changing or refreshing the token is not a corrective action here.

    Downloads

    There is no supported client-side bypass demonstrated for affected downloads. Microsoft Graph returns either a 302 redirect or @microsoft.graph.downloadUrl; that destination is a short-lived, preauthenticated URL and must be fetched without an Authorization header.^6^

    Generating a fresh download URL is useful only to exclude normal URL expiry. If a newly generated URL immediately returns the same delayed 401 BadContextToken, the failure remains at the content endpoint.

    Meaning of RequireReadOnly

    X-Ms-Invokeapp: 1; RequireReadOnly does not establish that the Microsoft account, drive, or token has been switched to read-only mode. No supplied Microsoft documentation defines that internal response field or maps it to an account state.

    Likewise, this is not a documented Microsoft Entra claims challenge. A standard claims challenge uses a Bearer WWW-Authenticate response containing an insufficient_claims error and a claims directive.^7^ Your response instead uses the legacy Wlid1.1 scheme and BadContextToken. Therefore, RequireReadOnly should be retained as diagnostic evidence, not interpreted as an actionable permission requirement.

    Monitor Microsoft service health and the rclone issue. Once the service recovers, ordinary chunked uploads and downloads should resume without reauthorizing or changing the remote configuration.


    References

    1. Microsoft service health status
    2. #10328 OneDrive Personal: upload fails with HTTP 401 Unauthorized on multipart upload PUT (can list, cannot copy)
    3. #192379 Backups to OneDrive fail on every attempt
    4. Graph api createUploadSession returns 401 on uploadUrl - Microsoft Q&A
    5. driveItem: createUploadSession
    6. Download driveItem content
    7. Claims challenges, claims requests and client capabilities
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.