Summary
OneDrive integration in ZimaOS is broken globally because the client_secret of the Azure AD application registered by IceWhale (client_id 0eb0522d-48a2-4115-a190-00c00514d29d) has expired. Microsoft Entra rejects every OAuth flow attempt with AADSTS7000222, and icewhale-files does not surface this error to the user — the OAuth popup closes silently.
This affects every ZimaOS user attempting to connect or reconnect OneDrive. The fix has to come from IceWhale: generate a new client_secret in the Azure portal, then ship it in a ZimaOS update.
Environment
- ZimaOS: v1.5.4 (build 2026/02/03)
- Files frontend: v0.0.34
- rclone: v1.70.0-DEV
- Hardware: ZimaBoard 2
User-visible symptoms
- OneDrive (and sometimes Dropbox) mounts disappear from the Files app.
- Attempting to re-add OneDrive: the OAuth login popup briefly opens and closes immediately before the user can sign in.
- No error message is shown in the UI.
- Backup jobs whose destination is OneDrive cannot complete.
- The browser console shows:
Uncaught (in promise) SyntaxError: "undefined" is not valid JSON
at JSON.parse (<anonymous>)
at tI.re (Files-D38fqq2b.js:2059:23612)
These symptoms match the following existing community reports, neither of which has been resolved:
- @MateusTorquato — My OneDrive / Dropbox mounts disappeared from Files app (Dec 18, 2025)
- @Malok88 — OneDrive connection issue – login dialog closes immediately (Mar 14, 2026)
Root cause (from backend logs)
journalctl on the icewhale-files service reveals the actual upstream error returned by Microsoft Entra during the OAuth callback:
May 10 16:14:50 ZimaBoard2 icewhale-files[1266]:
2026-05-10T16:14:50.477-0300 error Then init error:
{
"error": "AADSTS7000222: The provided client secret keys for app
'0eb0522d-48a2-4115-a190-00c00514d29d' are expired.
Visit the Azure portal to create new keys for your app:
https://aka.ms/NewClientSecret, or consider using certificate
credentials for added security: https://aka.ms/certCreds.
Trace ID: 436e0a48-a848-4251-80d3-ce80e14d8000
Correlation ID: aeeb1f0d-0b5f-45db-8680-639a4a508eb6
Timestamp: 2026-05-10 19:14:50Z",
"name": "onedrive",
"func": "route.(*APIRoute).GetRecoverCallback",
"file": "/home/runner/work/IceWhale-Files/IceWhale-Files/route/api_route_recover.go",
"line": 205
}
The Trace ID and Correlation ID confirm this response originated from Microsoft’s authentication servers, not from rclone or ZimaOS. It is not a local misconfiguration, network issue, MFA problem, or redirect_uri mismatch.
Microsoft’s official documentation for this error: https://login.microsoftonline.com/error?code=7000222
Why this affects every user simultaneously
Azure AD client secrets have a maximum lifetime of 24 months. When the secret of a multi-tenant application expires, every OAuth flow for that application fails for every user, instantly and globally. No per-user remediation is possible — only the application owner (IceWhale) can rotate the secret.
A directly comparable historical incident: Astiga (a third-party OneDrive integration for music streaming) suffered this exact failure mode in 2021. All their users were unable to connect to OneDrive until the provider rotated their Azure client secret. See Astiga — Azure client key expired for the post-mortem.
Why the UI silently fails
Two compounding backend issues hide the real cause from users:
- The error from
GetRecoverCallback(api_route_recover.go:205) is logged correctly, but the HTTP response body sent back to the frontend appears to be empty/undefined. - The frontend (
Files-D38fqq2b.js, functionre, around line 2059:23612) callsJSON.parse()on the response without guarding against an undefined value. The resultingSyntaxErroris an unhandled promise rejection, so the popup just closes — no toast, no console message visible to a non-technical user, no entry in any UI-level log.
Even after the secret is rotated, this graceful-error-handling gap is worth addressing separately — a clear “OneDrive sign-in failed, please try again” message would have saved a lot of debugging time for many users.
Reproduction (one-liner)
On any ZimaOS install, attempt to add or reconnect OneDrive in the Files app, then run:
journalctl --since "5 minutes ago" -u icewhale-files | grep AADSTS7000222
If AADSTS7000222 appears, the report applies.
Suggested actions for the IceWhale team
- Urgent: Generate a new
client_secretin the Azure portal for application0eb0522d-48a2-4115-a190-00c00514d29dand ship it in the next ZimaOS update. - Recommended: Migrate from client secret to certificate credentials, which Microsoft recommends for long-lived integrations and which can be configured with longer expiries (or auto-rotation). See https://aka.ms/certCreds.
- Add a calendar reminder to rotate the secret well before its expiry. Microsoft sends notifications, but they are easy to miss.
- UI hardening: In
Files-D38fqq2b.jsat the call site ofJSON.parse, guard against undefined/empty responses and surface backend errors (or at least a generic failure message) to the user. This is a small fix with high ROI for diagnosability.
For users currently affected
Until IceWhale releases a fix, OneDrive integration in ZimaOS Files is non-functional. Manual workarounds — registering your own Azure application and editing /var/lib/casaos/rclone.conf directly with personal client_id/client_secret values — are technically possible, but the Files UI and Backup app may not integrate cleanly with manually-created remotes (the UI adds custom fields like mount_point, used, total, username that aren’t part of standard rclone configuration).
I am happy to provide additional logs, run further diagnostics, or test a fix once available.
custom fork