Why are shared documents not updating in SharePoint or OneDrive?

When a shared document does not show another person’s changes in SharePoint, OneDrive or the Office desktop apps, it can look like a simple sync problem. In some cases it is a OneDrive sync issue, but in other cases the file cannot use normal Microsoft 365 coauthoring because of the way it is protected.

This guide covers a common situation where Office reports that AutoSave cannot be turned on because the file is encrypted, and the same document opens as read only on another computer.

Start with the quick checks first. The explanation later in the guide explains how SharePoint, OneDrive, AutoSave, encryption and read only behaviour fit together.

Use the links below to jump to the section most relevant to your question.

• What to check before changing SharePoint or OneDrive
• Why AutoSave can be blocked by encryption
• Why the file may open as read only
• How SharePoint and OneDrive coauthoring normally works
• Why protected files can behave differently
• Common causes of this problem
• A safer troubleshooting sequence
• What to check on managed business devices
• What not to do
• When to contact IT support
• How to reduce repeat issues
• Frequently asked questions
• Supporting references
• Further Guidance and Support

This issue can involve important business data, so the first step is not to remove protection or change several settings at once. The aim is to confirm which file is being opened, whether the file is protected, and whether OneDrive, Office or SharePoint is preventing normal coauthoring.

1. Confirm that both users are opening the same shared document, not a downloaded copy, email attachment, older local copy or separate version.
2. Check whether the file is being opened from SharePoint, OneDrive, Teams or a synced folder in File Explorer.
3. Check whether OneDrive is signed in, running and not showing sync errors.
4. Open the file in Word, Excel or PowerPoint and check whether AutoSave is available.
5. Read the exact AutoSave message shown by Office.
6. Go to File, then Info, and check the document protection area.
7. Look for password encryption, restricted access, marked as final, always open read only, or a sensitivity label.
8. Check whether the SharePoint document library requires files to be checked out before editing.
9. Open the file directly from SharePoint in the browser and compare the behaviour with the desktop app.
10. If protection needs to be tested, make a copy of the document first. Do not remove protection from the live file until it is clear why the protection was applied.

These checks help separate a sync delay from a document protection problem. They also reduce the risk of changing a protected document without understanding why the protection was applied.

If Office says AutoSave cannot be turned on because the file is encrypted, this is a strong clue. The issue may not be that OneDrive has failed to sync. The file may be protected in a way that prevents normal live collaboration.

AutoSave is important because it allows Office to save changes back to SharePoint or OneDrive while people are working. Coauthoring depends on Office being able to save and coordinate changes through Microsoft 365.

Encryption or protection may be applied in different ways. The file may use password encryption, restricted access, Information Rights Management, a Microsoft Purview sensitivity label, or another protection setting. Some of these methods can limit how the file is opened, saved or edited.

This does not mean that encryption is wrong. It means the protection method needs to match how the document is used. If the document needs both protection and live collaboration, the Microsoft 365 configuration and the label settings need to support that behaviour.

Read only behaviour can be frustrating, but it is not always a fault. It can be a protective behaviour that prevents conflicting edits when Office cannot safely allow normal coauthoring.

A file may open as read only when another user already has it open and coauthoring is not available. It may also happen because the file is checked out, marked as final, password protected, restricted by permissions, or controlled by a sensitivity label.

It is also possible that one user has edit access while another user only has view access. For that reason, permissions should be checked as well as the file protection settings.

If AutoSave is blocked because the file is encrypted and another computer opens the file as read only, the two symptoms should be reviewed together. They often point towards document protection, sensitivity label behaviour, check out settings, permissions or Office behaviour rather than a simple OneDrive delay.

In a normal Microsoft 365 setup, supported Word, Excel and PowerPoint files stored in SharePoint or OneDrive can be edited by more than one person. This is called coauthoring.

SharePoint stores the cloud copy of many shared business files, including files used through Teams. OneDrive can sync the file or provide access to it locally. The Office desktop apps then coordinate changes with Microsoft 365 while users work on the document.

When coauthoring is working correctly, two people can usually open the same supported document and make changes without one person needing to close it first. The document should not behave like an old style network file that only one person can edit at a time.

That is why having the file open on two computers is not normally the root cause by itself. The more important question is whether the file, Office apps, permissions, AutoSave, OneDrive sync and protection settings all support coauthoring.

Coauthoring needs Office to save, merge and coordinate changes through Microsoft 365. Some protection methods restrict how the file can be opened, saved or edited. When that happens, Office may disable AutoSave or open the document as read only for another user.

Microsoft lists several things that can block coauthoring, including files protected with Information Rights Management or Digital Rights Management when not applied through supported sensitivity label configuration, files that are checked out, unsupported file formats, files marked as final, and some Office policy settings.

Microsoft Purview sensitivity labels can be used to apply encryption and access restrictions to documents. However, encrypted sensitivity labelled files need the right Microsoft 365 tenant setting and compatible Office behaviour if AutoSave and coauthoring are expected to work in the desktop apps.

This is why the wording of the Office message matters. “AutoSave cannot be turned on because the file is encrypted” should not be ignored as a minor warning. It points to a protection or configuration issue that can directly affect collaboration.

The same visible problem can have more than one cause. These variations are worth checking before deciding that SharePoint or OneDrive is broken.

Common causes include:

1. 1. The file is protected with password encryption.
   2. The file has restricted access or Information Rights Management.
   3. A Microsoft Purview sensitivity label is applying encryption.
   4. The SharePoint document library requires check out.
   5. The file is marked as final.
   6. The file format does not support normal coauthoring.
   7. One user has edit permission while another user only has view permission.
   8. OneDrive sync is paused, signed out or showing sync errors.
   9. One user is opening a downloaded copy rather than the live shared file.
   10. One user is opening the file from Recent files and reaching an older or local copy.
   11. The Office desktop app version or policy configuration does not support the expected coauthoring behaviour.

The exact cause should be checked before protection is removed, permissions are changed, or the file is replaced.

A safer troubleshooting process keeps the document, the file location, the protection settings and the user permissions separate in your thinking. This reduces the risk of treating every collaboration issue as a simple sync delay.

Use this sequence as a general guide:

1. 1. Confirm the file name and shared file location.
   2. Check whether the file is stored in SharePoint, OneDrive, Teams or a synced folder in File Explorer.
   3. Ask both users to open the file directly from the SharePoint library or OneDrive web interface in the browser.
   4. Check whether the browser version allows editing or shows a read only message.
   5. Open the same file in the desktop Office app and check the AutoSave message.
   6. Go to File, then Info, and review protection, labels and read only settings.
   7. Check whether the file has been checked out.
   8. Check whether both users have edit permissions.
   9. Check whether OneDrive is signed in and syncing without errors.
   10. Test with a copy before removing encryption or changing a sensitivity label.
   11. If sensitivity labels are involved, review the Microsoft 365 label and tenant configuration.
   12. If the issue affects several files, review the library and tenant settings rather than only the individual document.
   13. Record what was changed and test again with both users.

This keeps protection changes as a controlled step, not the first step. In many cases, the issue may be understood by checking the file status and opening behaviour before changing Microsoft 365 settings.

On business devices, this issue may be affected by organisation policy rather than only by the local user or the document owner. Microsoft 365, SharePoint, OneDrive, Office policy settings, Conditional Access, sensitivity labels and device management can all influence how files are opened and edited.

This means a user may not be able to remove protection or change behaviour locally. In some environments, the restrictions are intentional because the organisation wants sensitive files protected, labelled or controlled.

For managed devices, check whether any of the following apply:

1. 1. The device is enrolled in Microsoft Intune or another management platform.
   2. The user signs in with a Microsoft Entra ID work account.
   3. The organisation uses Microsoft Purview sensitivity labels.
   4. The document library requires files to be checked out.
   5. Office policies disable or restrict coauthoring.
   6. External sharing or guest access is involved.
   7. Users outside the organisation are opening the file.
   8. Several users have the same read only or AutoSave behaviour.

If a device or tenant is managed by an organisation, manual changes to one file may not resolve the underlying issue. The policy, label or library configuration may need to be reviewed.

This issue can become harder to resolve if too many changes are made at once. The safest approach is to avoid destructive or rushed changes until the file status is understood.

Do not do the following:

1. 1. Do not assume SharePoint is broken because one file does not update as expected.
   2. Do not assume OneDrive sync is the only possible cause.
   3. Do not think the issue is related to the users having the file open at the same time.
   4. Do not remove encryption from the live document without checking why it was applied.
   5. Do not remove or change a sensitivity label without checking organisational policy.
   6. Do not overwrite the shared file with a local copy unless you understand which version is current.
   7. Do not ignore a read only message if users are expecting to collaborate.
   8. Do not treat one protected document as proof that the whole SharePoint site or OneDrive setup is misconfigured.
   9. Do not change several Microsoft 365 settings at once without recording what was changed.

These precautions are especially important where the affected document contains client information, financial information, HR information, legal documents or other sensitive business data.

It is sensible to contact IT support when the file contains important business information, when users are seeing different versions of the same document, or when Office reports that AutoSave is unavailable because the file is encrypted.

It is also sensible to get support when sensitivity labels, restricted access, SharePoint library settings or OneDrive sync errors are involved. These settings can affect more than one document and may need to be reviewed at file, library, device, user or tenant level.

When asking for help, provide the following information:

1. 1. The file type, such as Word, Excel or PowerPoint.
   2. Whether the file is stored in SharePoint, Teams or OneDrive.
   3. The exact AutoSave or read only message.
   4. Whether the file has a sensitivity label.
   5. Whether the issue happens in the browser, the desktop app, or both.
   6. Whether more than one user is affected.
   7. Whether the issue affects one file or several files.
   8. Whether the users are internal staff, external guests or both.
   9. Whether the file was previously protected, encrypted or moved from another location.

This information helps separate a single document issue from a wider SharePoint, OneDrive, Microsoft 365 or security configuration issue.

The same problem can return if document protection and collaboration requirements are not reviewed together. This is especially true where SharePoint, OneDrive, Teams, Office desktop apps and sensitivity labels are all involved.

To reduce repeat issues:

1. 1. Decide which documents need live collaboration.
   2. Decide which documents need encryption or restricted access.
   3. Avoid traditional password encryption on active shared working documents unless there is a clear reason.
   4. Use SharePoint permissions and Microsoft 365 access controls for normal shared access.
   5. Use sensitivity labels carefully where document protection is required.
   6. Test sensitivity label behaviour before applying it widely.
   7. Check whether encrypted labelled files support AutoSave and coauthoring in the tenant.
   8. Review document library check out settings.
   9. Confirm users understand whether they are opening the live shared file or a downloaded copy.
   10. Review shared document libraries periodically.

This should not be treated as a permanent checklist. Microsoft 365 behaviour, Office desktop apps, sensitivity labels and organisational security requirements can change over time. Controls should be reviewed periodically, and document protection should form part of a wider layered security approach.

Does having the same shared document open on two computers cause this problem?

Not normally. Microsoft 365 coauthoring is designed to allow supported files to be edited by more than one person when the file is stored in SharePoint or OneDrive and the configuration supports it.

Why does AutoSave matter?

AutoSave helps Office save changes to SharePoint or OneDrive while people work. If AutoSave is unavailable, the file may not support normal live coauthoring in its current state.

Why would encryption stop AutoSave?

Some protection methods restrict how Office can save, merge or coordinate changes. If Office reports that AutoSave cannot be turned on because the file is encrypted, the protection method and Microsoft 365 configuration need to be checked.

Why does the file open as read only for another user?

Office may open a file as read only to prevent conflicting edits when normal coauthoring is not available. It may also happen because of permissions, check out settings, document protection, sensitivity labels or read only settings.

Should we remove encryption from the document?

Not without checking why it was applied. Test with a copy first and review whether SharePoint permissions, Microsoft 365 access controls or sensitivity labels are the better way to protect the document.

Is this a OneDrive sync problem?

It could be, but the AutoSave encryption message and read only behaviour suggest that document protection or Microsoft 365 configuration should be checked first.

Does this mean encryption should not be used with SharePoint files?

No. Encryption may be appropriate for sensitive documents. The important point is that the chosen protection method must match the way the document is used. A document that needs live collaboration may require a different protection approach from a document that only needs controlled viewing.

Should users open the file in the browser or the desktop app?

Testing both is useful. If the file behaves differently in the browser and the desktop app, that can help identify whether the issue is related to the desktop Office app, local sync, protection settings or tenant configuration.

This guide is based on practical Microsoft 365 troubleshooting experience and Microsoft’s published documentation on Office coauthoring, SharePoint, OneDrive, AutoSave and sensitivity labels.

Microsoft Support: Troubleshoot coauthoring in Office.

Microsoft Learn: Enable coauthoring for files encrypted with sensitivity labels.

Microsoft Support: Document collaboration and coauthoring.

Microsoft Support: Turn on AutoSave in Microsoft 365 apps.

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing
London, United Kingdom

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
20 May 2026