6

When crawling my content I get the following error:

"45 https://something.com/sites/dcio Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled. "

The service account I am using has full read access to the web application.

I tried adding the DisableLoopBackCheck DWord to the registry, I added it to all my servers, and deleted the index, restarted them, crawled and still I get the same error. I used this guide

I am really curious about where this error is coming from.

Improve this question
4
  • When you say the account have full read access, are you referring to permissions within the site or user policy permissions from the web application in Central Administration?
    – John Chapman
    Commented Sep 14, 2011 at 15:39
  • @John Chapman, i mean i have added the user that runs the service to have full read permissions on the web application. I also added this to the main post
    – nldev
    Commented Oct 3, 2011 at 9:33
  • Well two things are usually the ones I started from when I hit these errors. 1) Add an inclusion rule for the site into the Crawl Rules and 2) Can you login to the site, using the Crawl Account, and see the content?
    – MichaelF
    Commented Oct 3, 2011 at 13:02
  • @ MichaelF what exactly do you mean by adding an inclusion rule? Do you mean a rule that includes the site in the crawl, because i thought that this was accomplished by adding the site to the content source?
    – nldev
    Commented Oct 3, 2011 at 13:15

6 Answers 6

Reset to default
2

This Solution worked for me:

You need to disable the LoopBackRequest in registry. To do this, just follow my instructions:

  1. Go to command window and type regedit.exe

  2. Once opened the registry editor, just navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa"

  3. Right click on "Lsa" and create a new 32bit DWORD value

  4. Rename it as "DisableLoopbackCheck" (Note: you cannot rename it actually. so, once created the DWORD value, directly paste/type as "DisableLoopbackCheck".

  5. Then again modify the value of "DisableLoopbackCheck" as "1"

  6. Close the registry editor.
  7. Now start to crawl the content.
Improve this answer
1

The content access account is not same as search service account. You can check the content access account on the Search Administration page, see System Status section. Make sure this account has read permissions on your web application.

Also you can change this account on the same section.

Improve this answer
3
  • It has, the account is SP_Service, this account also has full read permissions on the web application... Any more ideas?
    – nldev
    Commented Oct 17, 2011 at 14:12
  • It has what? SP_Service is a domain account?
    – Amit Kumawat
    Commented Oct 17, 2011 at 15:54
  • The content acces account, SP_Service, has read permissions to the web applications. It is a domain account.
    – nldev
    Commented Oct 18, 2011 at 6:47
1

Make sure the content access account has read access to the content databases: http://technet.microsoft.com/en-us/library/cc263445.aspx

The content access account...

Must have Read Access to the content being crawled. Full Read permissions must be granted explicitly to content that is outside the local farm. Full Read permissions are automatically configured for content databases in the local farm.

Improve this answer
2
  • The content acces account has full read acces on the web application. How do you mean giving full read acces to the content databases? In SQL ?
    – nldev
    Commented Oct 17, 2011 at 14:13
  • In SQL you grant the content access account the db_reader role on all content databases. This should be done by default, but if the order of steps were missed or if something else went wrong it may not be set.
    – Mike Oryszak
    Commented Oct 17, 2011 at 14:20
1

Oke, it turns out this being caused by our ISA server. We use the ISA server for load balancing and fail-over. This is something that SharePoint does not compute! When I turned the indexing server into a new WFE and added all applications to the host file pointing to the localhost, all the error messages disappeard!

I searched the internet for ages looking for an answer, i hope this one can spare someone from that experience.

Improve this answer
1

I also had a similar problem where my "Full Read" policy was in place, but when I logged in as the service account I still got "Access Denied" screens in some places...

Turns out this was due to my drafts settings. Since the service account didn't have edit, and drafts were visible only to editors, they weren't being indexed.

For now, I'm changing the user policy to "Full Control" but I'm hoping to find a better solution if there's one out there.

Improve this answer
0

The same issue showed up when I tried to crawl an SP2016 site with FQDN (sp.somedomain.com). The issue is not strictly SharePoint related, I saw it before with other sites using NTLM.

The solution was to create a new registry entry a follows:

  1. Go to HKLM/System/CurrentControlSet/Control/Lsa/MSV1_0 in Regedit
  2. New Multistring key: BackConnectionHostNames
  3. Value is the FQDN (without protocol or port!)
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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