Document is locked for editing
At some point in time, you will run into the DocumentName is locked for editing by ‘Username’ message when working with SharePoint. Most of the time, this is a very valid message and is notifying the user that someone else is already editing the document.
However, what happens when the message has your name there? How could this be possible? (On some occasions it will also say unknown.)
When you edit a document, SharePoint registers that you have this document open for editing. Once every 10 minutes or so, the Office product will check back in with SharePoint letting it know that it is still open by you. Once the document is saved and closed then Office will let SharePoint know that the document is now available to other users.
On some occasions you will receive the locked for editing message with your name there and no matter what you attempt to do you cannot get rid of the message (closing / reopening the document or restarting your computer does nothing to help rectify this).
This situation most commonly occurs under the following scenarios:
- The Microsoft Office product crashes while you were working on the document
- Computer freezes or crashes while document is open
- Lost of network connectivity while document is open
You might be wondering how this could happen if the document is stored in SharePoint? To understand how this situation can happen, it is helpful to understand how SharePoint and Office work together.
The following is a high level overview of the process:
- User clicks Edit in Microsoft Word from the drop down menu in a SharePoint document library
- Word launches and tell SharePoint that you have the document open for editing (locked for other users)
- A copy of the document is downloaded and stored in a hidden system folder on your local computer. By default, this is located in:
C:\Documents and Settings\UserName\Local Settings\Temporary Internet Files\Content.MSO
- Under normal circumstances, when you close the Office product, the file is removed from the Content.MSO folder
If someone occurs that prevents the document from cleaning itself up (such as one of the scenarios mentioned previously) it is possible that Office will continue to tell you the file is locked for editing.
The solution to the problem is to simply delete all the files out of the Content.MSO folder and attempt to open the document again from SharePoint.
Prior to deleting the files you may want to copy the files because it is also possible that the version stored on the hard drive is more recent than the one stored in SharePoint — I have seen this on rare occasions.
Update – 4/13/2010
Be sure to check out part 2 of this post the outlines another location you may need to check.
Comments
Comment from Tamer helmy
Time July 28, 2008 at 1:35 am
is there is any way to force office to check in the file
Comment from liebrand
Time July 30, 2008 at 7:52 am
Tamer,
To my knowledge, there is no out-of-the-box way of forcing Office to check a document back into SharePoint without user intervention.
If the document library has been setup to require checkout and major/minor version is turned on, then Office will prompt when the user saves whether they want to check the document in and make it a major version.
Comment from Marlijn
Time August 28, 2008 at 4:46 am
Hi Paul,
In our company, users are locked from documents by themselves on a regular basis. I’ve tried to delete the file from the Content.MSO-folder, but they still get the warning/error… I feel I’ve looked everywhere, but can’t find an answer… Do you have any other ideas???
Grtz. Marlijn
Comment from liebrand
Time August 28, 2008 at 8:46 am
Marlijn,
It is pretty rare for a document to get locked out. This should really only happen if for some reason the Office application unexpected quits (due to error, crash, etc). However, in my organization I have seen this problem frequently occur on users machines who have a mis-configured network card (the duplex speed). For example, we had users that were set on “Auto” however they were plugged into a switch that was set to 100/Full. Simply matching the network port speeds resolved the issue for these users.
When it comes to the “locked” message — there are two situations this will occur. If the document exists in the Content.MSO directory as outlined in this blog post. However, SharePoint will also put a “short-term” lock on the document when it is being edited. If the users closes the document, it will tell SharePoint to release the document. Once again, if the application unexpectedly, the SharePoint “lock” does not get cleared. The SharePoint lock will timeout after about 10 minutes if it detects the document is no longer open by a user (see this KB article for more information http://support.microsoft.com/kb/899709).
Hopefully this helps.
Comment from Marlijn
Time September 1, 2008 at 6:37 am
Hi Paul,
Thanks for your answer, it was very fast!
Still the KB you referred to, did not solve our problems, waiting for 10 minutes doesn’t help, it can easily take up to several hours before the “short-term”-lock ends and releases the document.
The network-card-problem you described might work… I’ll have to ask our System-management-guys.
The weird thing is, that there is no logic to the problem, not the time it happens, the person it happens to, or the computers it happens on.
If anything comes to mind about a possible solution, please let me know!!! I’m getting desperate
Regards,
Marlijn
Comment from liebrand
Time September 1, 2008 at 11:47 am
Marlijn,
Just remember… the network card issue was on the client desktops NOT the SharePoint servers. I just wanted to clarify that.
Paul
Comment from Joe
Time September 19, 2008 at 12:17 pm
I had the lock out problem also, and the link speed was the problem. Thanks!
Comment from Kool
Time November 5, 2008 at 12:04 pm
I have a similar, yet different problem.
An indiviudal checked out a file about 4 months ago and never checked it back in. During this time, she left the company, her user information has been removed from the system (including Sharepoint), and yet her UserID is still locking this particular folder that we are attempting to archive and remove.
Is there a trick or solution that I can try? So far I have only seen the “short-term” checkout – 10 minutes and a little about “long-term” checkout, but with no vable solutions. Your help is appreciated.
“Kool”
Comment from liebrand
Time November 5, 2008 at 12:18 pm
Kool,
Try this. Navigate to the document library that has the checked out document. Click on Settings / Document Library settings, and then selected Managed Checked Out Files.
If the document is listed here, try taking back ownership of the document.
Pingback from Documents locked when editing a document you opened « Uzma’s SharePoint Blog
Time February 18, 2009 at 4:32 am
[...] This issue is either caused by the MSOCache folder or the client Office lock out. See Paul Liebrand’s blog for more [...]
Pingback from "Document checked out" workflow issue in SharePoint document library – Schalk's evolutionary ramblings
Time February 22, 2009 at 9:51 pm
[...] The following post describes some other scenarios that also need to be catered for:Document is locked for editing [...]
Comment from Ned
Time March 23, 2009 at 1:35 pm
I have a client that is reporting that sharepoint no longer notifies them that a document is locked for editing by someone else. Have you ever heard of this and do you know how to turn this feature back on? Thanks!
Comment from liebrand
Time March 24, 2009 at 6:00 am
Ned,
I have never heard of this specific problem. I do not believe this feature can be disabled. What has changed in the clients environment recently? Have they upgraded to a new version of Office, Windows, etc?
Thanks,
Paul Liebrand
Comment from Ned
Time March 24, 2009 at 6:33 am
Thanks for the reply, Paul! I had the same thoughts about office and windows changes…but they of course report that nothing has changed. Thanks for the sanity check
Comment from liebrand
Time March 24, 2009 at 10:08 pm
Check what zone their browser believes they are in. I have seen some strange behavior if they are in the incorrect zone.
Paul Liebrand
Comment from Mehul
Time May 1, 2009 at 10:38 am
Hi Ned, did you find a solution to this? Our users reported this problem for the first time this week. It seems like there is no pattern to the problem, it’s very random. Thanks.
Comment from Ned
Time May 1, 2009 at 10:40 am
Hey Mehul, I asked them to do thorough testing of the issue and it turns out that it was user error. I’d def recommend doing the testing yourself with 2 accounts if possible. it was a training issue in our case.
Comment from Anu
Time June 12, 2009 at 3:48 am
Hi Paul,
Are you able to solve the issue?
Iam also facing the same issue. Though of removing the Content.MSO file but in my machine i dont have that Folder. I only have “Temp” and “Application … “Folders.
Please help me in this case.
Thanks in advance.
Anu.
Comment from liebrand
Time June 12, 2009 at 7:26 am
The CONTENT.MSO folder is a special hidden folder. You will not see it if you are just looking via Windows Explorer; you have to manually type in Content.MSO into the address bar.
The quickest way to insure you are in the right folder, do the following:
1. Start Internet Explorer and click Tools > Internet Options
2. Click Settings under Browsing History
3. Click View Files
This will put you into the Internet Explorer Temporary Internet Files folder. Now simply append Content.MSO to the path listed at the top of the Windows Explorer toolbar.
Thanks
Comment from Anu
Time June 12, 2009 at 7:52 am
Hi Paul,
Tried that (by displaying all the hidded files) but in my machine as well as in our server machine i did not find this folder.
Is there any other way to solve this?
Is the URL length an issue for this? as my url of the document what iam trying to open exceeded 256 charecters.
Iam not sure what the issue is but i want to get rid of this issue ASAP.
Please help me.
Thanks in advance.
Comment from liebrand
Time June 12, 2009 at 8:50 am
Anu,
I have never seen a client PC that does NOT have this folder when SharePoint and Office is involved which leads me to believe that either I am not explaining the process clear enough, or there is something odd and strange on your end.
The folder is not even visible when you tell Windows to show hidden files and folders. You HAVE to manually key it into the address bar in order to show it.
I have never seen a URL length issue cause this particular problem. I have seen Excel, Word, etc report that the URL is too long if it is too long but not this document is locked for editing issue.
Generally the locked for editing is caused by a computer crash or a network issue.
Comment from TFox
Time September 21, 2009 at 7:32 am
Suggested work around:
Have the users save a copy of the file locally. Once they are done making their changes, they can upload the file over the original file. As long as the SP file is checked in, I have had no problems with this work around. Sometime the newly uploaded file will be marked read-only, but the changes are made, saved and can be shared. Sometimes that is enought to make the user happy.
Comment from Marlijn
Time October 7, 2009 at 12:13 am
Hi Paul,
In our company, users are locked from documents by themselves on a regular basis. I've tried to delete the file from the Content.MSO-folder, but they still get the warning/error… I feel I've looked everywhere, but can't find an answer… Do you have any other ideas???
Grtz. Marlijn
Comment from Velmurugan
Time October 15, 2009 at 6:38 am
Hi, In our company sharepoint server having lot of folders & files and many users are checked out and forget it. How to find all the checked out files from various folder in simple way in admin level.
Or HOw to list out all the checked files from sharepoint?
Thanks in advance,
Velmurugan,
Comment from Paul Liebrand
Time October 15, 2009 at 10:21 am
You can run this SQL statement against your content database to get a list of items that are checked out:
SELECT AllUserData.tp_DirName,
AllUserData.tp_DirName,
AllUserData.tp_LeafName,
CASE
WHEN AllUserData.tp_ContentType = 'Item'
THEN
AllUserData.tp_DirName
+ '/DispForm.aspx?ID='
+ AllUserData.tp_LeafName
ELSE
AllUserData.tp_DirName
+ '/'
+ AllUserData.tp_LeafName
END
AS Link,
AllUserData.tp_ContentType,
AllUserData.nvarchar1,
AllUserData.nvarchar2,
AllUserData.tp_ModerationStatus,
AllUserData.tp_DeleteTransactionId,
AllUserData.tp_IsCurrent
FROM AllUserData AllUserData
WHERE (AllUserData.tp_ModerationStatus = 2)
AND (AllUserData.tp_DeleteTransactionId = 0×0)
AND (AllUserData.tp_IsCurrent = 1)
ORDER BY AllUserData.tp_DirName, AllUserData.tp_LeafName
I hope this helps.
Paul
Comment from Velmurugan
Time October 16, 2009 at 12:40 am
I ran this query. Please let me know how to find out the checked out files.
I am new to sharepoint server. please explain in detail.
Comment from Paul Liebrand
Time October 16, 2009 at 1:06 am
You need to connect to your SharePoint SQL database using something like SQL Management Studio and the run the query I provided against that database.
Are you running just WSS or MOSS?
Comment from velmurugan
Time October 16, 2009 at 3:41 am
I have run sql query in SQL Management Studio 2005 and we are using MOSS.
Comment from Paul Liebrand
Time October 16, 2009 at 8:34 am
I am confused. The query I provided above should give you a listing of all items considered to be checked out. Are you saying the query did not work?
Comment from velmurugan
Time October 21, 2009 at 1:38 am
Query is successful running.afterthat how to find all the checked out files.i am new in sharepoint server.please help me.
Comment from reddogaw
Time December 11, 2009 at 7:05 pm
Hi Paul,
I also need to overcome one of these locks… We have an InfoPath application, and we've written a custom webservice to pull out meta data and write it to our document library (as well as deal with checkin/out problems etc). This works fine…
Until: our client has the WebClient windows service active (to enable webdav etc) then open a saved InfoPath file. This makes the client put a lock on the file… Which means on subsequent saves, our file is totally locked out from our custom webservice (which is also executing as a different user – with write/undo check out/contributor rights in SharePoint).
Any ideas how to:
* Override the lock security?
* Undo the lock security (e.g. undo checkout)?
We are using WSS3.0. And our webservice is communicating using the WSS3.0 Web Services rather than the object model…
Comment from reddogaw
Time December 12, 2009 at 1:05 am
Hi Paul,
I also need to overcome one of these locks… We have an InfoPath application, and we've written a custom webservice to pull out meta data and write it to our document library (as well as deal with checkin/out problems etc). This works fine…
Until: our client has the WebClient windows service active (to enable webdav etc) then open a saved InfoPath file. This makes the client put a lock on the file… Which means on subsequent saves, our file is totally locked out from our custom webservice (which is also executing as a different user – with write/undo check out/contributor rights in SharePoint).
Any ideas how to:
* Override the lock security?
* Undo the lock security (e.g. undo checkout)?
We are using WSS3.0. And our webservice is communicating using the WSS3.0 Web Services rather than the object model…
Comment from Peter Martin
Time March 1, 2010 at 3:34 pm
Paul – I am trying to upload some files that I colleague who used to work here had from 2008. I'm getting the locked message on about half of his files. The file names are not in SharePoint because I've added a “final” to the end of them. Any ideas what's causing the lock message?
Thanks, Peter
Comment from Paul Liebrand
Time March 2, 2010 at 4:05 am
Are you sure it is related? Perhaps you are suffering from the “special” character issue. http://support.microsoft.com/kb/905231
Comment from Mark P
Time March 29, 2010 at 1:07 pm
Hi Paul,
I'm not sure if you can help, due to internal policies and procedures, the fix involving the network cards is not an option for us. do you know of any way to eliminate the lock time out, or reduce it to for example 1 minute?
All the best
Mark P
Comment from Paul Liebrand
Time March 30, 2010 at 4:16 pm
Mark,
Unfortunately I do not believe the is a way to eliminate the lock time out or reduce it. I have found no reference to any setting that can modify this behavior. Perhaps forcing your users to checkout the document to the local drafts folder can be an option to work around the issue.
Paul
Pingback from Document Locked Mystery « SharePoint From Scratch
Time April 12, 2010 at 12:13 pm
[...] first goes into detail here and follows up with a companion article [...]