"Error:The file is locked" when using Office Online within SharePoint Online

[snyderdavida]

At a current client I am seeing this scenario play out often:

1) User clicks on an Office document in a SPO document library, and it opens in a new tab in the associated Office Online app. They make an edit, the edit is auto-saved, and close the new tab. Or, they don't need to make any edits, just needed to view, so they close the tab.

2) In the original tab, they attempt to add metadata, or delete the file, but are told the file is locked. It then needs to time out before anyone can make edits to the file, and there doesn't appear to be any way to release the lock manually. 

The file would not be locked if the user refreshed the document library page after closing the additional tab, but this is not realistic to expect the user to know to do to avoid locks. 

I would like such documents to open in the same tab so the user would have to trigger a refresh when returning to the library. As far as I can tell this is not an option in settings - is this true? Is Microsoft aware of this bug? It is causing untold issues.

[#2]

@SkinnyPetebuuu. I will keep you posted if I manage to work anything out- got 2 IT teams looking into it independently. 

[#3]

We are having the same issue but only with one person. Everyone else is able to create and edit documents. Would love to know a way to fix this!!

[#4]

@Tammy BrunsI was advised that the protocol is (in simple terms):

The system keeps asking the browser if the document is closed, and once they get a positive response, then it allows the action in sharepoint.

This may be actually something to do with browser settings/internet.

If I find out any more I will update :)

Good luck and Happy New Year!

[#5]

@barbaracummings Thank you!

[#6]

We faced same ISSUE.

Maybe for last month from time to time.

Any solusion?

[#7]

hm....

All who faced same issue...is it only doc, xls files?

or docx and xlsx also have this "lock" bug?

[#8]

We are experiencing the same issue with Visio files 

[#9]

@MIX_DP  We primarily see the issue with excel.  My users have been experiencing this issue for the last week.

[#10]

@Carrida 

When user is using recent versions of Chrome or Edge Chromium based, the files are not unlocked properly when they close the document in Office web app!  
Office web apps relies on the "Sync XHR"-event which are blocked by default in these modern browser.  See the following article.
https://dev.to/okms/office-online-the-file-is-locked-for-shared-use-error-15mh

This is also happening in SP (Office web apps) On Prem!  MS needs to fix this!

[#11]

@snyderdavida Microsoft, it's been 2 years. 
When are you going to fix this basic database error? When the user closes out of the document, the database should always read unlocked. Please implement a solution to this issue. 

[#12]

@DELTAResources they are slowly working on it. At the moment at least admin can delete a document even if the document is showing as locked. 

Everything there seems to be taking forever......

[#13]

Hi

The best approach i have found so far is (get the user that has a lock on the file or yourself if you are the culprit) to go back into the document within office online and in the top right where it has a button that says Editing click and change to the view mode. This will unlock the current user from holding a lock on the file.

Huw

[#14]

@HuwSy we shouldn't have to do that though, especially if we are using Microsoft Flow and "Move File" automations. Teams and users do not have the attention or time to make sure every file is unlocked prior to documents moving. Instead, we receive error messages and have to go in and unlock the file. 

That's unacceptable in 2020.

[#15]

@DELTAResourcesI couldn't agree more. 

[#16]

@HuwSy thats a great tip, thanks. I didn't know about it.

[#17]

@DELTAResources Hi, its not ideal but its at least functional. And if you have libraries with checkout and check in anyway (we do on most libraries) then its just part of the process.

[#18]

@HuwSy we use Checking In/Out as well, but for this specific team, we turned off that setting because individuals were forgetting to check in prior to submitting to flow. Can't tell which problem is worse: getting them to check-in documents or Microsoft SharePoint being unable to distinguish between locked and unlocked documents 

[#19]

Guys, I do not know if any of you were able to figure out the resolution for this issue. But there seems to be a bug in Office Online Server. Office Online Server relies on the allow-sync-xhr-in-page-dismissal browser flag in EDGE and CHROME browsers to sync the check-in/check-our status of a document, Both browsers are built on Chromium OS. As of Oct 2020, chrome has updated their stance on disabling this flag for performance / security reason. More here : https://www.chromestatus.com/feature/4664843055398912.

So, the issue happens to be that OOS dependency on allow-sync-xhr-in-page-dismissal flag to sync back status updates back to SharePoint. Since, this flag is now disabled, users when they open documents in any chromium based browser, will see that the document is checked out every time they try to edit it. They will not be able to edit the metadata, since the document will never be checked in. And on top of that, You will see that when editing by the same user, it shows their names multiple times, indicating that someone else is co-authoring the document at the same time.

I have validated this behavior in Office Online Server On-Prem with SharePoint On-Prem.

MICROSOFT, you guys should fix this issue as this is hurting our production users and we seem to have no way to control it as some of the users are external and we do not manage their machines/browsers.

Here is a WORKAROUND : In Chrome or Edge, open applicable flags shown below

• Edge chromium: edge://flags
• Chrome: chrome://flags

Navigate to #allow-sync-xhr-in-page-dismissal flag, flip the flag from Disabled/Default to Enabled. 

You will have to restart your browser for it take effect. Now, try editing the document in browser. Remember, you may still see that 1 or more of YOU are still co-authoring the document. To mitigate this, you will have to clear the Office Online Server cache.

Hope this helps some of you, who may be looking for a workaround.

Credits: https://dev.to/okms/office-online-the-file-is-locked-for-shared-use-error-15mh

[#20]

@NavinKanus Thank you for this brilliant information.

This saves us hours of trying to figure out the root cause. Now, where's the permanent solution for SharePoint Server 2019 and OOS Microsoft! 

[#21]

Great Stuff! Still seems weird that such a problem in a very common production scenario that already exists for 3 years, does not have some peeps at MS upping the prio on this.

Especially considering that the "Sync-XHR method while exiting a tab/page" has been deprecated a long time for a reason: security concerns.

Alternatives in the form of 'SendBeacon' and 'Fetch keep-alive' seem to exist btw.