Forum Discussion
"Error:The file is locked" when using Office Online within SharePoint Online
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.
40 Replies
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 edge://flags/#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
NavinKanus - I cannot see that particular flag so unable to follow your advice, so out of exasperation I installed Firefox - with astonishing results - and good ones. I have thrown the kitchen sink at it and FIrefox has let me down once so far. Very satisfying. Thanks for the pointer to a browser issue.
- 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. 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!
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.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......
We faced same ISSUE.
Maybe for last month from time to time.
Any solusion?
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!!
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!
barbaracummings Thank you!
I have had the same issue recently as myself locking the file. Although it was resolved by clicking back into the file in office web apps and instead of closing the tab I clicked the library name at the top of the page so the browser navigated away from the page which managed to unlock the file. It could be to do with how they have hooked the onunload event to the page and how this is supported in different browsers and for different scenarios.
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
HuwSy thats a great tip, thanks. I didn't know about it.
- We have the same problem. I hope microsof's support will start to solve this problem and come up with a satisfactory solution. It is annoying to tell tenant users that the only possible way is to wait 10-15 minutes, or refresh the website.
- We've seen this lock issue intermittently as well, and they usually release in 10-15 minutes, but sometimes it's longer. We're trying to keep track if the files have macros and/or if they're being synched to their OneDrive clients.
- Bumping this to hopefully keep it alive. As a company that nearly exclusively uses SharePoint for document storage and collaboration, this is a very annoying issue.
Chameleon_Queue_90 One of our in flight projects is SharePoint roll out, if this isn't fixed by the time we go live, it's probably going to be a show stopper. Turning on force check out isn't an option as we have already had a lot of push back from the business over that......
Also having the same problem, issue for us is people would open a document to view the information and when they closed it the file would stay locked out to them.
Have found what appears to be a work around but may not fit everyone's needs if you want multiple people to amend at once.
If you have admin rights under Library Settings>Versioning Settings there is an option 'Require Check Out' that for us was defaulted to 'No'. I changed to 'Yes' and this then forces people to check out the document which then means people have to consciously select edit the workbook.
Yes, seems to be happening for us still will_b .
No workaround for us seems to do the trick unfortunately.
Andrew Silcock We have exactly the same issue and there does not seem to be a workaround, other than waiting for 30 minutes until the lock clears. This is absolutely unacceptable from a support perspective, users are not going to live with that.
- Also happening for us on occasion, seems to happen across multiple users on the same day and then resolves itself after a few days.
Definitely a wide issue and something Microsoft need to fix permanently!
