Menu
On our SharePoint 2007 SP1 farm, intermittently, when a user opens a Microsoft Office document (usually Excel) for editing by single-clicking its name in IE, the following error dialog mysteriously occurs when Office opens: File in Use myfile.xlsm is locked for editing by 'domainname yourname' Open 'Read-Only' or click 'Notify' to open read-only and receive notification when the document is no longer in use. The problem is, nobody else is editing this document, and the identified user ('domainname yourname') is the name of the current user (the person opening the document right now)! This is not 'user error', e.g., the same user editing the file from two different computers, or the file being checked out. This is a real, intermittent problem. If the same user opens the same file again 1 minute later, the problem might be gone, even though nothing changed. It's almost as if some kind of intermittent race condition is happening, where the document gets locked too early.? We are completely stumped.
May 02, 2015 Re: [Solved] 'XXX' File Locked For Editing - Mac by RoryOF » Sat May 02, 2015 5:41 am Usually, a left over lock file is indicative of either a program/operating system crash, or too speedy a close down of the computer after exiting OpenOffice. One user (currently using Office for Mac 2011) recently tried to access a Word document on the file server, but was notified that the file was locked for editing by another user. The problem is that she's the only one who accesses the file.
Other details: - SharePoint servers (1 front-end, 1 query, 1 indexing) are all Windows 2003 Server - SQL Server 2008 on database server - Clients are mostly Windows XP - Our versioning model is: - Content approval: not required - Document Version History: Create major versions - Require Check Out: No. I agree: Office Web Apps is not a viable solution to this problem. The feature set available in Office Web Apps can not compare to the features available in the client app. Due to the limited feature set, Office Web Apps rarely works as an enterprise-wide replacement for the client.
I feel for you guys. It was a huge headache for me when I was getting this problem, too. Watching the network traffic with Fiddler is what led us to our load balancer as the culprit. The networked request from Office to SharePoint to lock/unlock the file was failing. Even though you have a single WFE, I would still recommend inspecting the network traffic. There may be something else in your network (a switch, router, hub, etc.) that is causing problems with a request somewhere along the line. If nothing else, you mayat least see that the traffic is all clear and can scratch my solution off your list.PaulE- PS-We've had no troubles with our SharePoint Server 2010 farm which was deployed after our solution was found. Thank you Xue-Mei: Let me see if I understand this correctly.
Just now, I opened a Word document, made a small edit, and saved. I did it 5 more times in a row, quickly.
Nothing stopped me: I did not see a 'locked for editing' message. I assume the write lock is being removed when Word exits. Based on the KB article, it sounds like this 10-minute write lock applies only if the editing program has terminated abnormally, leaving the write lock in place. This I understand. However, my clients are not saying anything about Word or Excel crashing.
They're just opening a SharePoint file and getting the 'locked by yourself' error. I have not seen any evidence that our users are experiencing a crash beforehand. Perhaps even when the application exits normally, sometimes the write lock is left around, i.e., a Microsoft bug.
That being said. When my users encounter the problem, sometimes a few seconds later (not 10 minutes), the problem goes away. So I'm not completely convinced this is the cause. But it's the likeliest story I've heard so far.
Any other thoughts? Hi, You Can try this: When User clicks Edit in Microsoft Word in a SharePoint document library Word launches and tell SharePoint that a document is opend 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 Normally, 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 Network connectivity Lost etc.,), 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.Make Sure U take backup before deleting:) Let me know the results.
Has anyone fixed this? The more people in our organization start using SharePoint the more often this is happening and the more I am getting yelled at by users. Deleting the content.mso is unnacceptable since usually they have saved a more recent copy and it is in the drafts folder. Waiting 10 minutes is not acceptable either.
I don't know what could be happening or if connectivity is actually dropped because I never notice losing connectivity to anything at any other time nor do your sysadms see anything. I know that the interal lock is the problem since when I use the sharepoint administrator software to go look up the document i can see the internal lock. I was wondering if I wrote something to use the object model to remove this lock would it work? Then I can instruct the site administrator how to use it. Edit: that won't help much now that I think of it, they'll still have to upload the latest version again. I am telling people to try this solution as a workaround, but haven't heard from anyone if it works: the business side is not happy with giving users a complicated workaround when most of them are not very computer savvy.
The other idea I am trying is have them change the 'Save' setting under Word/Excel Options from local drafts to web site. Maybe it will keep saving there and that will cause it to stay in communciation with the server. We are finding that the users having this problem are on Windows 7 or Windows Server 2008. The latest is that if these users don't go through the load balancer (i.e. They put a HOSTS entry that points the domain name for our SharePoint site to a single WFE), things work fine.
We've captured a few Fiddler sessions whereby the UNLOCK request fails to get a response when going through the load balancer, but I've also seen cases where LOCK and OPTIONS fail (OPTIONS typically fails as 'unauthorized'), as well. I don't have anything to suggest as a solution yet, but thought others might want to know that we've been able to resolve some problems by eliminating the load balancer from the loop. I'm working with our Network Admin to see if he knows any reason this may be (who knows; maybe he's blocked those types of http requests for some crazy reason!). The investigation continues! Xue-Mei Chang's answer is technically correct but incomplete and impractical.
The 10-minute write lock exists, but it also happens without warning to individual users, locking themselves out in the middle of an editing session:. User Smith edits a document. User Smith keeps the document open and continues editing. In the middle of the session, the SharePoint server 'forgets' that Smith has the document locked. It releases the lock. User Jones opens and edits the same document.
User Smith, who still has the document open, tries to save and is told Jones has it locked, even though Smith originally locked it and had it open the whole time. User Smith gets angry and stops trusting SharePoint. The only answer I get from Microsoft on this, repeatedly, is, 'There's a 10-minute write lock.' Microsoft never says, 'Step 3 is a bug,' even though it clearly violates version control and locking, in a manner I have never seen in any other system.
I am the original poster of this thread. Our solution, unfortunately, has been to get rid of SharePoint. So, after discovering that our locking issue did not occur when we bypassed the load balancer, we talked with our network admin in charge of the F5 device. We had been using cookie-based load balancing. In this scenario, the F5 load balancer tacked on a session cookie along with the HTTP response from the SharePoint WFE. The cookie identified to the load balancer which WFE was serving the user. Our network admin made a couple of changes to the way the F5 device was load balancing and we have no longer had the locking issue.
I don't know the details, but he mentioned something about 'performance layer 4' (one-to-many router setting) and changing the sticky sessions to be based on source address (i.e. The user's IP address). Looks like it won't help dbturtle any longer, but maybe this info can help keep others from taking the same abandonement approach. Dbturtle, Sorry that you are having issues.
The issue here is the version of Office that you are using. Are you using Office 2003 or Office 2007? With Office 2003 it is not a full integration with SharePoint 2007 because Office 2003 was out prior to SharePoint 2007. Because of this Office 2003 does not have the proper mechanism to lock the files in SharePoint.
If your clients are running Office 2003 then your document library should not be set to required checkout. Office 2007 should not have these problems because it was built to work with MOSS 2007 and has a full integration.
It knows how to lock the file correctly. Hope this helps, -Aseem This posting is provided 'AS IS' with no warranties, and confers no rights. Hello, I understand your frustration. I would not go as far to say this is a bug since this seems only to be affecting you and most often it is something environmental causing it (like a load balancer). I would suggest you open a ticket with Microsoft Support and ask for the Office Client SharePoint Integration team.
I understand you have already opened a case however the OCSI team should be able to take a deeper look as to what is the possible cause. Thanks, -Aseem This posting is provided 'AS IS' with no warranties, and confers no rights.