Cannot Edit Documents in SharePoint

Question

We have MOSS 2007 installed.  From this implementation, I run a site that has all that SharePoint has to offer and another site trimmed down to just Windows SharePoint Services functionality.  Recently my users have reported and problem to me that they find irritating.  It happens on both my sites where I run SharePoint Server and Windows SharePoint Services.  The odd thing is that it does not happen on all the sub sites created under these two top-level sites.  Users that have reported the problem have contribute and full control permissions on the sites in question.

"This document could not be checked out to your local drafts folder. The document may have already been checked out, or the local drafts folder could not be written to."

 

My users are using MS Office 2007 and run Windows XP SP and Windows Vista SP1.

 

If anyone could be so kind to help me I sure would appreciate it.  I have search all available resources that I am aware of and have yet to find anything that points me to a solution.

 

Thanks,

 

 

Answer 1

Any luck resolving this?

 

Answer 2

Nasty! Here's a few things to check:

• What zone is Internet Explorer detecting the web site as (bottom right of your web browser window). Ensure that it is in the Intranet or Trusted Sites zone
• Do these users have the SharePoint Drafts folder in their My Documents folder? If so, can they copy a file into it?
• They are using Internet Explorer - right?
• Do you have automatic check-out enabled? Does it make a difference if you disable this option?

Ivan

Answer 3

 

Any luck resolving this?  I have the same issue.

Answer 4

I have the same issue with two users.  No reported issues from anyone else.  This is a big problem.

I've seen some tech notes that proxy configuration may also cause some trouble like this but we do not have this configured.  We also have the MOSS server in the "trusted sites" zone.

Answer 5

What is this

"where I run SharePoint Server and Windows SharePoint Services. "

supposed to mean.

You already said you have MOSS 2007 - so why do you say that some sites run "SharePoint Server and Windows SharePoint Services" ?

You can't run both products on the same server. 

Answer 6

I've resolved the problem on one of the laptops by doing a repair on the MS Office 2007 install.

Answer 7

I have the same issue. I have the site in my trusted sites list.

Actually I have a test environment and production. No problem checking out on the Test but Production I get this error. I'm using the same PC and browser. The production environment is behind a different firewal which is doing NAT though .... but I'm clutching at straws here :-)

Answer 8

Has anyone been able to correct this issue? I've come across it recently as well, but with an interesting twist.

The following error occurs,

“This document could not be checked out to your local drafts folder.  The document may have already been checked out, or the local drafts folder could not be written to.”

when I click OK, the following error then immediately occurs,

“The document could not be opened for editing.  A Windows SharePoint Services compatible application could not be found to edit the document.”

We are running MOSS with Project Server 2007.

These errors only occur in certain Folders within certain SharePoint Document Libraries. It isn't consistent.

A workaround was discovered. We check out the file manually, then open the folder and the Desktop in Windows explorer, make our changes and save them on the Desktop, then copy them back into SharePoint. On Checkin, it gives us the ability to add a new version with comments.

This is really annoying and time consuming. Any assistance would be greatly appreciated.

Answer 9

Did you check the location of the local drafts folder on the local client, and if the users have access to it? You can do this e.g. in Word: click the Office button, click on Word Options, go to the Save category and check the Server drafts location...

Answer 10

Is client integration turned off for the web application that contains the site that you're attempting to access documents?  Just throwing it out there...

More than likely it is not since it sounds like things are working for one of the client machines properly post fixing your 2007 installation.

---

http://www.spdan.com

Answer 11

We had the same problem and discovered that it was because we had exceeded the 260 character UTF-16 limitation for SharePoint paths (see http://support.microsoft.com/kb/894630). After we shortened the length of some of our subfolders, this resolved the problem.

Hope this helps,
Eric Barker
http://www.barkerzone.net

Answer 12

This issue has flummoxed me for close to a month.  Our original nine month (MOSS 2007 Enterprise) test site and the proposed MOSS 2007 (Standard) production site have been affected with the same inability to edit and save documents that have the Forced Check Out feature turned on.  Many of the original sites from the original (Enterprise) test site collection are fine, and are still fine after migrating to the (Standard) production site via SP Designer.  This issue only occurs to new subsites and their (forced Check Out) document libraries.  There are no content types that have required columns (neither Item nor Document).    We’ve set up a third site for further testing, but have not been able to replicate the issue.  Strangely, now when I open a document from one of the affected sites a subfolder structure that corresponds to the SharePoint structure is created within “SharePoint Drafts” folder.  Example:    C:\My Documents\SharePoint Drafts\huddle\departments\is\sysadmins\Server Documentation\filename.docx

When forced Checked Out files are opened from the non-affected (third) site, their local copy is stored in the root of C:\My Documents\SharePoint Drafts\   This folder structure creation seems to only happen to me, yet everything else seems to be consistent with all others.  (I did do an Office Repair, might be the cause)

All of this has to be a site issue because our successful third site environment is built on the same server as one of the affected sites.

And yes to all the other items listed in this thread (Trusted Intranet Zone, no proxies, and I do have permissions to my local folder), and an example of URL length is in the area of 96 characters.  I understand exceeding 260 can cause problems.