Paul Liebrand’s Weblog

Welcome to my blog mainly about SharePoint

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:

  1. The Microsoft Office product crashes while you were working on the document
  2. Computer freezes or crashes while document is open
  3. 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:

  1. User clicks Edit in Microsoft Word from the drop down menu in a SharePoint document library
  2. Word launches and tell SharePoint that you have the document open for editing (locked for other users)
  3. 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

  4. 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.


January 4, 2008 - Posted by | SharePoint


  1. is there is any way to force office to check in the file

    Comment by Tamer helmy | July 28, 2008 | Reply

  2. 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 by liebrand | July 30, 2008 | Reply

  3. 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 by Marlijn | August 28, 2008 | Reply

    • 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.


      Comment by Anu | June 12, 2009 | Reply

      • 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.


        Comment by liebrand | June 12, 2009

    • 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 by Anu | June 12, 2009 | Reply

      • 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 by liebrand | June 12, 2009

  4. 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

    Hopefully this helps.

    Comment by liebrand | August 28, 2008 | Reply

  5. 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 😦


    Comment by Marlijn | September 1, 2008 | Reply

  6. Marlijn,

    Just remember… the network card issue was on the client desktops NOT the SharePoint servers. I just wanted to clarify that.


    Comment by liebrand | September 1, 2008 | Reply

  7. I had the lock out problem also, and the link speed was the problem. Thanks!

    Comment by Joe | September 19, 2008 | Reply

  8. 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.


    Comment by Kool | November 5, 2008 | Reply

  9. 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.

    Comment by liebrand | November 5, 2008 | Reply

  10. […] This issue is either caused by the MSOCache folder or the client Office lock out. See Paul Liebrand’s blog for more […]

    Pingback by Documents locked when editing a document you opened « Uzma’s SharePoint Blog | February 18, 2009 | Reply

  11. […] The following post describes some other scenarios that also need to be catered for:Document is locked for editing […]

    Pingback by "Document checked out" workflow issue in SharePoint document library - Schalk's evolutionary ramblings | February 22, 2009 | Reply

  12. 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 by Ned | March 23, 2009 | Reply

    • 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?


      Paul Liebrand

      Comment by liebrand | March 24, 2009 | Reply

    • 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 by Ned | March 24, 2009 | Reply

      • 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 by liebrand | March 24, 2009

    • 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 by Mehul | May 1, 2009 | Reply

  13. 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 by Ned | May 1, 2009 | Reply

  14. 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 by TFox | September 21, 2009 | Reply

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: