Forum Discussion

avallesalas's avatar
avallesalas
Copper Contributor
Sep 07, 2026

Confirming this issue — additional technical detail that may help narrow down the root cause

I'm experiencing the exact same behavior described in this thread, and wanted to share some additional diagnostic detail that might be useful, since it points to a possible contributing factor beyond a generic sync failure.

Environment:

  • macOS Tahoe 26.6.2 (25G83)
  • Mac mini
  • OneDrive standalone install, version 26.153.0809.0004
  • Microsoft Word, Version 16.112.3 (26090417) — issue persists after updating from 16.112.3 (26083020)

Symptoms (identical to those already reported):

  • AutoSave toggle OFF when opening any .docx/.xlsx/.pptx file via double-click from Finder, even though the file is correctly synced (folder shows the cloud icon, manual save uploads correctly, sharing links work fine).
  • Word reports "Saved on My Mac" instead of the OneDrive/SharePoint location.
  • Manually enabling AutoSave prompts to "upload" the file, as if it had never been in the cloud.
  • After that upload completes, closing and reopening the same file resets AutoSave to OFF again.
  • Opening the same file via Word > File > Open > Online Locations correctly recognizes it as a cloud document and AutoSave works normally — this is consistent with what others have reported.
  • Reproduced this with brand-new files created and saved directly from Word into the OneDrive folder, not just pre-existing files.

Ruled out (verified via terminal diagnostics):

  • OneDrive File Provider extension is registered and enabled (pluginkit -m -A -p com.apple.fileprovider-nonui shows it active).
  • The File Provider domain for the account is alive and healthy (fileproviderctl dump), with the affected file showing ul:uploaded status and no error counters.
  • The UBF8T346G9.OfficeOneDriveSyncIntegration shared plist (the mechanism OneDrive uses to publish synced folder metadata to Office) is correctly populated with all my synced libraries, including the personal OneDrive root, updated same-day.

Possible contributing factor — Unicode normalization mismatch:
My organization's OneDrive folder name contains an accented character ("Gestión"). Comparing the on-disk path (as returned by Finder/the filesystem) against the MountPoint value stored in the OfficeOneDriveSyncIntegration plist, I found:

  • On-disk path: NFD-normalized (decomposed: "o" + combining acute accent, \xcc\x81)
  • Plist MountPoint value: NFC-normalized (precomposed "ó", \xc3\xb3)

Both strings are visually identical and normalize to the same value under NFC or NFD, but differ byte-for-byte. If Office performs a literal/byte-exact comparison rather than a Unicode-normalized one when matching a local path against known cloud-synced locations, this would explain why the cloud identity fails to resolve — while the underlying OneDrive sync engine (which doesn't need to do this comparison) keeps working normally.

I want to flag that I have not found confirmation that this is a necessary condition — other reports in this thread and the related Tech Community thread describe the same symptoms without mentioning accented folder names, so this appears to be, at most, a contributing factor in some environments (possibly organization/tenant names with non-ASCII characters), layered on top of whatever broader regression was introduced around the macOS Tahoe 26.6 update.

Happy to provide further diagnostic output (fileproviderctl dump, log traces) if useful for triage.