2

SharePoint 2010 is crawling many file share locations. The crawls have been throwing up thousands of errors of the type:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

We have setup several domain accounts for various purposes. One of them is the "SearchAccess" domain account that has READ permissions to the entire file share! In fact, I verified that the SearchAccess domain account has READ permission to these file share locations that are throwing out the Access denied errors.

Any help in the right direction is very much appreciated.

Update: I tried a suggestion to set DisableLoopBack to 1 in the Register under SYSTEM\CurrentControlSet\Control\Lsa. This did not help.

|improve this question
  • How did you verify? Does your Domain Controller note that the permissions are correct? If SP says access is denied then something is not set right somewhere. – MichaelF Nov 10 '11 at 14:20
  • It might not have propigated to folders or items that could have unique permissions in the file share. Have you verified that the file(s) throwing the error do in fact have the search account listed as having read access? – Eric Alexander Nov 10 '11 at 14:25
  • Well the default content access account in my case "searchaccessprod" belongs to a group named "SearchAccess". This group has READ access to all the folders in the file share. This was verified by going to some of the folders that said "Access denied" and checking permission levels for "SearchAccess" – badikumar Nov 10 '11 at 15:30
2

It turns out that this is not a permission issue. The Shared Drive is set to FULL permissions for all users and the fine-grained permissions for the different folders are controlled with NTFS permissions.

The "Access Denied" errors were actually thrown because of other issues with ifilters.

Further investigation led to the following results:

SharePoint 2010 throws out the dreaded "Access Denied" errors as a catch-all, it seems. Access Denied was thrown for all the file types of the following nature:

  1. Files with no extensions when given an extension were indexed fine.
  2. Files with .txt extension created on UNIX only with LF at the end of line without a CR were rejected as "Access Denied". When CR was added, the files were indexed no problem.
  3. Same thing with a .xml file that was created on UNIX.
  4. PDF files which were scanned images instead of text returned "Access Denied"
  5. Partial HTML files without an opening and closing HTML tag returned "Access Denied". When an opening and closing tag were added, it indexed them fine.

Obviously, these are results of poor engineering of the ifilters that extract the content out of these files. Also, these are just the files we were able to investigate. Our file shares are so huge there there are a few million files and SharePoint throwing out tens of thousands of errors!

|improve this answer
  • Do you have a link to a knowledge base article or something like it? – Kelly S. French Oct 23 '12 at 14:24
1

We had this same issue: in our case this was NOT an permisssion issue. The files that are excludes all have an property called 'Blocked'; This property appers to be stored in an alternate data stream. we removed the alternate data stream with this tool: sysinternals streams http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx

|improve this answer
0

You need to ensure the default content access account has read permissions to your file shares. This account is used by crawler to index a content source.

You can also change the default content access account as mentioned here : http://technet.microsoft.com/en-us/library/cc261796.aspx

|improve this answer
  • Well the default content access account in my case "searchaccessprod" which belongs to a group named "SearchAccess". This group has READ access to all the folders in the file share. – badikumar Nov 10 '11 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.