Office for Mac no longer recognizes OneDrive files for AutoSave – “Saved on My Mac”

Carina 10 Reputation points
2026-08-10T18:14:01.01+00:00

Since a few days, Word and PowerPoint on my Mac no longer automatically save files to OneDrive.

My files are stored in my company's OneDrive folder and OneDrive itself appears to be working normally. The files sync correctly between my Mac and OneDrive.

However, when I open a Word or PowerPoint file, Office shows “Saved on My Mac” and the AutoSave toggle is OFF.

If I manually switch AutoSave on, Office tells me that I need to save/upload the file to OneDrive. I can do this successfully, but after I close the file and open it again, AutoSave is OFF again and the file once again shows “Saved on My Mac.”

Details

macOS

Microsoft Office/PowerPoint version: 16.111

OneDrive version: 26.134.0713

OneDrive is a business/company account

Files are stored under: ~/Library/CloudStorage/OneDrive-BUSINESSNAME/

  • Example file: ~/Library/CloudStorage/OneDrive-BUSINESSNAME/FILENAME.pptx

Troubleshooting already tried

OneDrive appears to be syncing normally; there are no general sync problems.

I always open the files directly from the OneDrive folder in Finder.

I also tried opening the same files through PowerPoint → File → Open → OneDrive. AutoSave is still OFF.

I tested with a newly created presentation, not just existing files. After saving it to OneDrive, closing and reopening it also results in AutoSave being OFF.

I signed out of my business Microsoft account in Office and signed in again. The problem persists.

I checked for Office updates, but Office reports that 16.111 is up to date.

This makes it seem like Office is no longer recognizing files in my OneDrive folder as OneDrive/cloud files, even though OneDrive itself is syncing them correctly.

Is there a known issue or a way to reset the Office ↔ OneDrive integration without reinstalling/resetting the entire OneDrive setup?

Microsoft 365 and Office | OneDrive | For business | MacOS

10 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Julien HUBSCH / ISRT 0 Reputation points
    2026-08-11T06:50:48.46+00:00

    Hi,

    We have been experiencing exactly the same issue since last Friday on five different Macs, with the same symptoms described here.

    OneDrive sync works correctly, but Office no longer recognizes files opened from the local OneDrive/SharePoint folder as cloud files, so AutoSave remains disabled.

    Microsoft, please investigate this issue urgently. This is seriously impacting our daily work.

    Was this answer helpful?

    7 people found this answer helpful.
    0 comments
  2. Soporte - G&C Legal 0 Reputation points
    2026-08-20T21:20:43.21+00:00

    Tenía el mismo problema, realice las siguientes acciones y funciona.

    Reset completo de OneDrive

    Antes de reinstalar nada, haría un reset del cliente.

    1. Cierra Word, Excel y OneDrive.
    2. En Finder selecciona:

    Ir > Ir a la carpeta

    1. Abre:

    /Applications/OneDrive.app/Contents/Resources

    1. Ejecuta:

    ResetOneDriveApp.command

    Si existe una versión standalone:

    ResetOneDriveAppStandalone.command

    1. Espera que OneDrive vuelva a iniciar.
    2. Inicia sesión nuevamente.
    3. Deja finalizar la sincronización.

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  3. Antonio Valle (G2) 5 Reputation points
    2026-09-07T21:19:23.0933333+00:00

    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.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.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  4. Andrea Confalonieri 5 Reputation points
    2026-09-04T12:47:06.4233333+00:00

    Hi,

    I'm facing the same issue. This is my configuration:

    macOS 26.6.2

    OneDrive 26.150.0804.0011

    Office 16.112

    I tried all the solutions that I found here and on other Microsoft relate sites. These can solve the problem for a limited time (hours), then it appears again.

    In addition to all these troubleshooting, I also did a complete reset of my MacBook, with disk initialization and a clean install of macOS. At first boot I only installed OneDrive and Office. As it did before, it all worked for a couple of hours and then the problem appeared again. So, don't waste your time in trying a macOS reset.

    I can't think of a more thorough and deeper attempt at a full system reset, so I think the problem should be solved by Microsoft. I hope that they could fix it soon because this is a HUGE problem in everyday workflow.

    A.

    Was this answer helpful?

    1 person found this answer helpful.
  5. Kai-L 19,050 Reputation points Microsoft External Staff Moderator
    2026-08-12T15:52:51.6433333+00:00

    Dear Carina, 

    Thank you for taking the time to work through both of those steps, and I am sorry neither resolved it.

    To answer your question directly: yes, given that other users are reporting the same behavior, a issue in the current OneDrive or Office for Mac version does now look like the most probable explanation. Your testing has effectively ruled out the local causes, which is genuinely useful evidence in itself.

    This is precisely why I would encourage escalating it to Microsoft, as I mentioned earlier. A support engineer can confirm whether this is a known regression in the current build, and if it is, your report contributes to getting it prioritised and fixed. It also means you would be notified once a fix ships, rather than having to keep testing blindly. I hope this gets addressed quickly. If you do hear back from support, I would be genuinely interested to know the outcome, as it would help others hitting the same issue.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

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.