Cannot Release Lock on SharePoint Online File

MattStOnge The error you're seeing is expected. Anytime you open an Office file from SharePoint (any version, SharePoint 2010, 2013, 2016, 2019, Online, etc) using Office (2010, 2013, 2016, 2019, 365 Pro Plus, Office for Mac, etc), you are guaranteed to set a file lock. That's how the product works.

There are two types of locks that can be set, and Exclusive file lock, and a Co-authoring file lock. Which lock type is set is dependent on a few key factors. When opening Office files, SharePoint will always attempt to set a co-authoring lock first. If a co-authoring lock cannot be set, SharePoint falls back to an exclusive file lock.

Exclusive file locks act exactly as their name implies. User opens the file, because of certain factors (addressed below), an exclusive file lock is set by the user's session in SharePoint. As long as that lock is in place only the user who set the lock can edit the file. If the user saves the file when they're done and properly exits the file (doesn't put the PC in sleep mode with the file open, doesn't just close the laptop lid and walk away, doesn't leave the file open for hours on end, and instead either uses file > Close, or waits for the file to completely save, then closes out of the client), then Office can send the proper network traffic to indicate it's done with the file and SharePoint will release the lock. This is known as exiting gracefully from the file, and applies to both file lock types.

Co-Authoring file locks are applied when the file is in a state that allows co-authoring and if the user is in a client that supports co-authoring. Whenever a file is opened in Office Web Apps, Office Online Server, or Office for the web, where the file can be edited in the browser, a Co-authoring file lock will always be set.

Certain Office clients (installed on your Windows or Mac machines) do not fully support Co-Authoring. For example, Co-Authoring in Excel is only supported on Office 365 Pro Plus version 1808 and newer. All other Office desktop clients do not allow for Excel co-authoring, and will always try to set an exclusive file lock.

Outside of the Office clients, there are other factors specific to the file and where the files stored that determine what file lock type is set. For example, all of the following to cause only Exclusive file locks to be set:

• The SharePoint library where the files are stored has "Checked required for editing" enabled. Even if opened in the browser, only exclusive file locks can be set for files within such a document library.
• IRM controls on the SharePoint library or the file.
• Setting the registry key "fsshttpoff" to a value of 1 (this is NEVER recommended)
• Turning off the OneDrive Sync client "Use Office applications to sync Office files that I open" setting (this should be left 'On' by default).
• Using the legacy Office file formats (*.doc, *.xls, *.ppt) instead of the current XML based file formats (*.xlsx, *.docx, *.pptx)
• Syncing files with the old and deprecated groove.exe OneDrive for Business sync client.
• And a few other, rarer factors.

MattStOnge, for you, it sounds like other users have set a co-authoring lock on the file, but your machine can only set exclusive file locks. Since the file is Excel, check that your Office client actually supports Excel Co-authoring. If you're not on the Office 365 Pro Plus client on any of the current update channel builds  (1902, 1908, 2002, 2003, 2004) then you're never expected to be able to edit the Excel file in the excel client app in near real time with your colleagues. I would compare what version of Office you're using with that of your colleagues. If it's the same version, then your machine has another factor at play preventing you from joining the Excel file's Co-authoring session.

This functionality is more than just SharePoint or Office, there is a lot more in play. What settings are set in the SharePoint Document library, on the file itself, in the Office client, on your windows/mac machine, what group policy settings are set (if your local user account and machine are domain managed), all of these matter and can affect what type of file lock your Office client can set, and by direct relation, what can be done with said file.

carlSteffen 

Glad to hear that worked. That's not a workaround however, that's how the product works.

When you close out of a file stored in SharePoint , Exiting the file gracefully (File > Close, Red 'x', etc.) your machine sends information back to SharePoint telling SharePoint that you're done with the file and the lock can be released. Once SharePoint receives that Trigger, it releases the file's lock.

File locks will always happen when opening files from SharePoint, that is 100% how the product works. Where issues can be seen is releasing the lock states. If you're not co-authoring, (whether this is disabled for you somehow or if your Office client doesn't support it), then you'll set an exclusive file lock. This means only the user who opened the file from SharePoint (The user who sets the lock state) will be able to edit the file.

Unless the user exits the file gracefully, or the lock expires, no one else can edit the file. If the user does not exit from the file gracefully (Application crashed, unexpected Power Reset, etc), then the lock will be released via an expiration setting built into SharePoint. If the lock state doesn't expire, the user can re-open the file and exit gracefully to try and remove the lock.

If you're seeing the file lock does not release after a user exits gracefully from the file, you could be looking at an issue with SharePoint, your local machine, or your Office client. More often than not, these lock issues aren't actually bugs or errors and come down to understanding how these products work and how the Office files are being opened or used.