Sharepoint 2016: Intermittent file locking issue when creating a document from a library

Jussi Lehti 601 Reputation points
2020-09-08T10:09:08.097+00:00

Lately we've been having weird file locking issues in our PROD and QA farms when creating a new document in a library.

And by creating a new document I mean creating it from the "New" button and not by uploading a document from my computer.

Right after I have created the document and edited the content and giving it a name the file seems to be "locked for shared use" by me.

I can edit the content of the document, but if I add some metadata to the file's properties and try to save the document Sharepoint throws an error:

The file "xxxxxxxxxxxxxxxxxxxxxxx" is locked for shared use by i:0e.t|xxxxx|xxxxxxxxxxxx. (which shows my account)

Also when viewing that document in Word desktop client my name appears two or three times in the section where you can view who has opened this document for editing (Share-button in the top-right corner)

The file is unlocked if I wait for about 10-60 minutes and after that everything works as intended.

We and our customers don't remember facing this issue before (in 3-4 years) and I have no clue why this issue is happening now.

I found a dirty workaround from another forum:

  • Go to document library settings and enable document checkout option and save. Then go to the same settings and disable it and save. (Even if it was disabled already like in our case).

Sounds weird, but that seems to work. Now if I create a new document from the library I can edit/save metadata to the document immediately without the file being locked by me.

What's even more weird this issue went away from me the day after I found this issue, but it still remains with our customer and also with my colleague.
All I did was cleared Office download center cache, but that didn't do anything. Surprisingly the next day I didn't have the issue anymore.
I suggested our customer to do the same, but that didn't help so I dont think that has anything to do with solving the issue for me.

So I don't have a clue why this issue is happening now and what is causing it and why the issue went away from me suddenly, but still occurs with other users.

Any ideas?

SharePoint Server
SharePoint Server
A family of Microsoft on-premises document management and storage systems.
2,232 questions
SharePoint Server Management
SharePoint Server Management
SharePoint Server: A family of Microsoft on-premises document management and storage systems.Management: The act or process of organizing, handling, directing or controlling something.
2,813 questions
0 comments
Accepted answer
  1. Jussi Lehti 601 Reputation points
    2020-09-10T07:36:51.727+00:00

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jussi Lehti 601 Reputation points
    2020-09-08T10:30:41.327+00:00

    A quick update to this post:

    That document library settings' "checkout option enabling/disabling"-workaround doesn't work with my colleague.

    New documents are still getting locked and he cannot add/save metadata to those documents.

    So this issue gets even more weird...

    0 comments
  2. MichaelHan-MSFT 18,016 Reputation points
    2020-09-09T09:26:22.843+00:00

    Hi anonymous user,

    Per my test, I could reproduce your issue on my SharePoint 2016. This seems to be related with the browser. Below is my test result:

    1. In Chrome broswer, I created the document via OOS. Then closed the document. I got the same error as yours when editing the properties of the file: The file is locked is locked for shared use by myself. This issue also happens when I edited the existing file in the browser. 2.In IE browser, everything works well after I closed the file. I would not get this error.

    I would suggest you try use IE browser. May be other browsers would not work well with SharePoint.

    Besides, I find some similar issues here. And the explaination is:

    Windows SharePoint Services puts a write lock on the document on the server. The write lock times out after 10 minutes. Users cannot modify the document during the time when the document is locked.

    https://social.technet.microsoft.com/Forums/Azure/en-US/7966c35d-b815-4951-8374-d64840ccf16c/documents-becoming-quotlocked-for-editingquot-by-self-when-no-other-edits-are-happening?forum=sharepointadminlegacy

    https://sharepoint.stackexchange.com/questions/202665/the-file-is-locked-for-exclusive-use-by-same-person-sharepoint-online

    If an Answer is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

  3. Jussi Lehti 601 Reputation points
    2020-09-10T07:09:51.31+00:00

    I did some testing with IE, Chrome and Edge (Chromium) and it seems only with IE the file doesn't get locked right after creating it.

    After some digging I found a reason why this is happening with Chromium based browsers: https://dev.to/okms/office-online-the-file-is-locked-for-shared-use-error-15mh

    chromium based browsers all have the flag allow-sync-xhr-in-page-dismissal.

    This flag can be found under
    Edge chromium: edge://flags
    Chrome: chrome://flags

    Recently it seems the default value for this flag has been changed to "disabled". Furthermore this flag will be removed from both Chrome and Edge. If this functionality is disabled, users will frequently experience issues where recently edited office documents are locked for editing by other users and metadata cannot be changed by the current user from the web interface.
    Office Online seems to rely on this functionality to unlock documents when you navigate away from the document editor interface. If not able to unlock a document, an exclusive lock will remain on the document until it expires after 30 minutes.

    So in Chrome I navigated to chrome://flags and enabled that allow-sync-xhr-in-page-dismissal flag and restarted Chrome and the problem went away. Newly created documents are not getting locked anymore.

    I could share this information with our partner who administers our clients' computers and policies if they can push that change to the end users.

    Apparently that will not be a permanent solution if that flag is being completely removed at some point from Chrome like mentioned in the quote above.

    It's also mentioned that this "temporary fix" is being removed from Chrome in future version 88: https://developers.google.com/web/updates/2019/12/chrome-80-deps-rems