Windows  ·  high  ·  Microsoft Office

AutoSave is greyed out, or saving fails with "Upload Failed"

A document in OneDrive or SharePoint will not save back, offering only to keep a local copy. AutoSave being unavailable is usually a symptom of the same thing: Office does not believe the file is in a location it can co-author from.

What you see

The AutoSave toggle is greyed out on a file that is plainly in OneDrive, or a save produces "Upload Failed" with a Save a Copy button. Sometimes an "Upload blocked" or conflict pane appears with two versions to reconcile.

What is actually wrong

Co-authoring needs the file opened through the sync client or from the service, with a valid sign-in. Opening the same file through a mapped drive to a SharePoint URL, a UNC path, or a second copy of the folder outside the sync root gives a path Office cannot co-author from. Where the file is in the right place, the cause is usually a stale token or a genuine edit conflict.

Codes and articles

Upload Failed officeAutoSave greyed outwe couldn't save your changesmerge conflict officeKeep a copy office

Start here — find out which fix applies

A script that runs the 2 inspection commands from the write-up below and prints what each one returned. It reads the machine and changes nothing — every command that could write, delete, start or stop is excluded from it by construction. Run this first, then pick the fix its output points at.

Download the read-only diagnosticchanges nothing · safe to run before reading

Fixes (3)

Rescue the work first, then resolve the conflict
The Office application20 minuteslow riskreversible

Always do this before anything else. Everything below risks the unsaved changes that are sitting in the open window.

  1. Do not close the document, and do not restart anything. The only copy of the unsaved work is in memory in that window.

  2. Use Save a Copy, or File → Save As, and write the file to the local disk with a new name — the desktop is fine.

    This is the single most important step on this page. Every other fix here involves closing the file or signing out, and any of them will discard the changes if they have not been written somewhere first.

  3. Confirm the local copy opens and contains the work before going any further.

    PowerShell
    Get-ChildItem "$env:USERPROFILE\Desktop" -Filter '*.docx' | Sort-Object LastWriteTime -Descending | Select-Object -First 3 Name, LastWriteTime, Length
  4. If a conflict pane is showing, work through it — it shows your version against the server version and lets you choose per change. Resolve it before saving.

  5. Once the work is safe locally, close the document and reopen it from the sync folder, then paste or merge the changes back.

Confirm it workedThe document in OneDrive contains the work, version history shows the new save, and the local copy can be deleted.
If you need to undo itThe local copy is the rollback — keep it until the version in the service is confirmed correct.
Download this fix as a PowerShell script4 steps you do yourself · asks before each step
Open the file from a location that can co-author
Explorer and the OneDrive client30 minuteslow riskreversible

The file was opened through a mapped drive, a UNC path, or a copy of the folder outside the sync root.

  1. Find out what path the document is actually open from — File → Info shows it under the file name.

  2. Check whether that path is inside the sync root.

    PowerShell
    Get-ItemProperty 'HKCU:\Software\Microsoft\OneDrive\Accounts\Business1' -ErrorAction SilentlyContinue | Select-Object UserFolder, DisplayName

    A mapped drive letter pointing at a SharePoint URL, or a second synced copy under a different profile, gives Office a path it will not co-author from. The file saves locally and the sync client uploads it afterwards, which is where the conflicts come from.

  3. Close the document and reopen it from the OneDrive or SharePoint folder in Explorer — the one with the cloud status icons — or from the browser via Open in Desktop App.

  4. Where a mapped drive to SharePoint is in use across a team, replace it with a synced library or a shortcut added to OneDrive. Mapped drives to SharePoint are not supported for this and break in exactly this way.

Confirm it workedAutoSave can be switched on for the document, and saving completes with no Upload Failed message.
If you need to undo itNothing changed on disk — the file is simply being opened by a different route.
Download this fix as a PowerShell script3 steps you do yourself · asks before each step
Refresh the sign-in behind the sync
PowerShell as the affected user40 minutesmedium riskreversible

The path is correct and the work is safe locally, but saving still fails. This fix signs the user out and clears the document cache, both of which discard changes that were never uploaded — take the local copy from the first fix before you start.

  1. Confirm the work is saved locally first, as above. This fix signs the user out.

    Signing out of Office closes documents. Anything unsaved at that point is gone, and this is the step where that happens.

  2. Check the sync client is running and not paused or in an error state — the cloud icon in the notification area shows this.

  3. Sign out of Office from File → Account → Sign out, close every Office application, and sign back in.

    PowerShell
    Get-Process WINWORD,EXCEL,POWERPNT,OUTLOOK -ErrorAction SilentlyContinue | Stop-Process -Force
  4. If it persists, clear the Office document cache, which holds the local copies Office uploads from.

    PowerShell
    Remove-Item "$env:LOCALAPPDATA\Microsoft\Office\16.0\OfficeFileCache" -Recurse -Force -ErrorAction SilentlyContinue

    The cache is where an upload sits when it fails. Clearing it discards pending uploads that were never going to succeed — which is why the local copy taken earlier matters. Office rebuilds the cache on the next open.

  5. Reopen the document from the sync folder and confirm it saves.

Confirm it workedA test edit saves and appears in the version history in the browser within a minute.
If you need to undo itThe cache and the sign-in both rebuild themselves. The local copy from the first fix remains the safety net.
Download this fix as a PowerShell script3 steps you do yourself · asks before each step

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.