What to do when MOSS 2007 refuses to recognize a user? RRS feed

  • Question

  • Running MOSS 2007 SP1.

    Site's doc libraries have history and "must check out before editing" options turned on.

    User is included in site's "members" group, which is listed as having contribute rights.

    User is in a doc library to which members have contribute rights

    User can sign out most of the files.

    One file,however, is being treated differently. The file is an .htm file stored in the doc library. User has to use the drop down menu on the item to select Edit with Microsoft Word.

    He checks out the document. It's icon changes to reflect this appropriately.

    He selects the Edit with... word opens.

    He receives a dialog that says:

    Title bar: File In Use

    Body: file.htm is locked for editing by 'another user'

    Do you want to:

    Radio buttons:

    Open a Read Only copy

    Create a local copy and merge your changes later

    Receive notification when the original copy is available

    Buttons: OK and Cancel

    We check the document library - the document is still checked out to him.

    He checks the document in. He selects Edit with...

    He is prompted that documents need to be checked out before editing and asked if he wants to check it out. He clicks OK.

    Word starts, and he then sees the File In Use dialog mentioned above.

    Does anyone have any ideas on what needs to be done in this case?  Why would the File In Use dialog refer to 'another user' instead of the name of the user? It seems to me that it isn't recognizing him.

    HOWEVER, the user assures me that yesterday, when this problem first surfaced, he was able to edit at least one other document in the same library without a problem.

    Thursday, July 21, 2011 1:39 PM

All replies

  • Hi Ivirden,


    You run into this problem because when a document is opened by a client program, 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 even though he is the user who previously opened the document.


    To work around this behavior, wait 10 minutes before you click Edit in ProgramName to open the document again.


    Hope this helps.


    Rock Wang

    Regards, Rock Wang Microsoft Online Community Support
    Friday, July 22, 2011 4:56 AM
  • I am having a hard time understanding this situation. Here's what we see - User A wants to edit a document, located on a library which requires one to checks out the document before editing.

    So User A checks out the document. 

    According to your description, this creates a write lock for the document on the server. Why would it do this, if the person is asking to check it out - one doesn't check out a document to the be unable to edit it.

    User A then finds that he is unable to edit the document because it is checked out to "another user'. However, the check out says that he is the person who has the document checked out.

    Telling someone that every time they want to change a document they much check it out, then wait 10 minutes, doesn't seem optimal.

    Also, the user checks out other documents in the same library without having this experience - why would this happen only with some users and some documents. His co-workers can check out the same document he's struggling with and make changes to it.

    Interestingly enough, a work-around seems to have been discovered. While I don't understand why this works, one of the things I tried was to add this user to the site's "members" group again. I didn't delete the old entry - just added him as a new user (replacing the old entry).

    When I had him test the document again, he was finally able to check it out and edit it.

    I was thinking that perhaps the group entry for him might be stale (somehow having old information) and that by making certain that his current info was inserted into the group, it might help. While it did, I do not understand why.

    Friday, July 22, 2011 2:04 PM