Solution for "The file [filename] is locked for exclusive use by [account-name]"
An option should be added to the "FILES" tab (when a document is selected) to unlock a document that "is locked for exclusive use by [user]"
As advised by O365 support, currently the only workaround is to download a copy and re-upload.
Ryan Greenaway commented
How is this even a problem in a modern document management system? I've just encountered this in SharePoint Server 2019. I create a file in SharePoint, it opens in the browser, I make changes, close the file and then go to add my mandatory metadata and the file is locked for exlcusive access...to me! I can't even edit the metadata.
I have also come to this problem, when trying to update some metadata to document library.
The only way I can get a user to unlock the doc is to ask them to restart. Please make a solution to this problem. Its been going on for too long.
This wreaks havoc with any automation processes on Document libraries (Flow/SPD) since when the file is open, nothing can edit the metadata fields on SharePoint. This absolutely needs to be resolved. At least allow metadata changes while files are open for a start.
Thanks, this solution worked for me.
The workaround, although it is not my preferred method, is to request of the user who has it locked to restart their computer. That will break the account hold on the file.
Just refresh the page
Marc Schaaks commented
More than often I have encountered this exclusive file locking issue. At the least an API method should be made available and even better an administrative UI method should be provided to query and resolve exclusive file locks.
I found another workaround:
Simply use another browser! You should now be able to checkout the file you have problems with and check it back in.
After that use your original browser.
Greetings from Germany
Creating a copy is not a workaround for documents with version control, as it doesn't copy across the version history. This is a frustrating bug.
Not sure how this is not available as an option, or at least a way to do this in SharePoint Online. There are at least script-able ways to do this on premise. How is there not a work around or something for Online?
Christopher Nolan commented
Normally, the issue happens when a document was opened in an Office client program, and the program was not closed properly.
When a document is opened by a client program, 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.
Regarding the situation, please wait 10 minutes, click Edit in ProgramName to check it in normally in the client program, and then check the outcome in Word Online.
North Gork commented
@Al Connelly I wrote an application page that uses the SharePoint API to unlock a document if it is an "Exclusive" file lock or a "Shared" file lock. I assume a "Shared" file lock is what you mean by "co-authoring" file lock?
Even after unlocking the file via the SharePoint API, the file is still locked so I suspect the lock is in the Office cache on the client machine. Perhaps in the windows cache too but locked on the client machine as a result of some authentication between Office and SharePoint that does not work properly.
Nitin Jain commented
This is killing me with no solution...
Ryan Helmer commented
We really need a way administratively to unlock a file. Telling users they have to wait for an arbitrary timeout period is definitely not well-received.
The problem could also be because of reaching the limit of minor versions (511).
Step 1: Publish a major version and check if that didn't solve the issue then try Step 2.
Step 2: Download a copy and upload it again that will solve the issue as it solved for me.
Al Connelly commented
This is likely already going to be fixed with improvements to coauthoring. there are two different lock states that can be set for a file hosted in SharePoint: an Exclusive file lock, and a Co-authoring file lock. Whoever opens the file sets the lock state. Exclusive locks are set by users who either can't use modern co-authoring (Like opening an Excel file using Office 2016 MSI instead of Click to run on the monthly channel) or using File check out. SharePoint sets the lock state and releases the lock state once it hears back from the Office client that whoever opened the file has closed out of it and the file is no longer in use. If SharePoint never hears back from the office client, then SharePoint won't unlock the file. In that case, SharePoint will remove the lock once the User's session expires (Usually a couple of hours at most). When a co-authoring lock is set, any user who can co-author can access the file without issue. The first user (who can co-author) sets the co-author lock state. The lock will also include that user's user session ID generated by SharePoint. Any other user who opens the file to co-author will have their session ID added to the file's co-authoring look, ultimately saying "Hey! I'm in this file too!". Only when all users leave the file will the co-authoring lock be released. The "The file [filename] is locked for exclusive use by [account-name]" message is expected behavior. What should be addressed is reliable having SharePoint receive the "I'm done with the file!" call from the Office client so it properly unlocks the file.
Tom Castiglia commented
Its pretty embarrassing that this is still a common problem for so many SharePoint users.
It's my first word file upload and it's locked. So frustrating :(
Django Lohn commented
Very nasty hidden feature... when someone opens Word Online by mistake (because that is default for libraries) the file is locked blocking all kind of workflows and edits!