Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Search crawl log Error: "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."

I've checked the search account and everything seems to be correct.

  • Search Admin Web Service domain\sp_search
  • Search Query Web Service domain\sp_search
  • Web Applications User Policy domain\sp_search set to 'Full Read'

This is a clean installation with SP1 installed. Have I missed anything?

Hope you can help.

Policy for Web Application

share|improve this question
    
Is the web application it's trying to crawl set with integrated authentication? –  PirateEric Aug 10 '11 at 12:15
    
Please give us details of the content source that is giving the error. –  SPDoctor Aug 11 '11 at 14:21
    
Hi. It fails to crawl MySite and our Default web application (Content Source: Local SharePoint Sites). The error message I get is detailed above. –  Frank O'Donnell Aug 16 '11 at 11:10
    
To PirateEric: I believe so. How can I confirm this? Thanks –  Frank O'Donnell Aug 16 '11 at 11:14

6 Answers 6

up vote 5 down vote accepted

Maybe you are running into a loopback authentication issue. This will happen if content is accessed from a server to the same server using an alternate DNS name. For example:

  1. Server name: srvSP2010wfe
  2. Portal URL pointing to server (1.): http://portal
  3. DNS config: portal A IP.OF.Server.1

The resolution is described here:

http://support.microsoft.com/kb/896861

The article is mentioning two methods:

Method 1 is setting the Key to disable the LoopBackCheck in general. This is considered less secure, but in real life it is easier during debugging the problem. Maybe you can disable it and if the solution works i would suggest to use the back connections host method to fix the problem.

Method 2 is setting a multi-string value. The string must contain all url's + FQDN (portal and portal.domain.local) that are not the machines hostname. Using this method is more secure because only selected url's are excluded from the loopback check. During debugging in a complicated setup this is harder to get right if you hit this for the first time.

After configuring the needed method to successfully run through the loopback check the index on the local machine should be able to access the content if the content access account has the needed privileges.

More info's on configuring the default access account are here: http://technet.microsoft.com/en-us/library/cc261796.aspx

share|improve this answer
    
Marco you're a genius. I disbaled the loopback and kicked off the crawl. I would be grateful if you could elaborate on the 'back connections host method'. Thanks again. –  Frank O'Donnell Aug 17 '11 at 11:01
    
I've edited my post to get you some more information about the issue. Thanx for the genius ;-) –  Marco Scheel Aug 24 '11 at 7:33
    
I 2nd the Genius nomination. Marco thank you for the clear explanation and solution to my issue after I enabled https on our SharePoint MOSS 2007 server. –  Chris Magnuson Jun 23 '12 at 18:32
    
Agree, this is genius - can't tell you how much time this saved. Also works in 2013. –  lukiffer Nov 26 '12 at 21:38

I suggest you go to the search administration page and explicitly set the default crawl account. It is a link in the System Status area, and if you follow it you can enter the account and password. Do this even if you already have the correct account name. I have found it doesn't always work unless you set it here, possibly because it is not picking up the password.

share|improve this answer
    
Hi. No luck with this solution either. Your help is appreciated. –  Frank O'Donnell Aug 11 '11 at 11:04

There is one time I've had this error when I knew that the content access account had the appropriate permissions. That is when I have created a web application and only created site collections in managed paths and nothing at the top level. For example, we created a web application: portal.mycompany.com and then created the site collections of portal.mycompany.com/teams/team1, portal.mycompany.com/teams/team2 but we did not create a site collection at portal.mycompany.com because we were not ready to start putting content at that level. However, we still wanted to search the contents from the other site collections. I always got this error. The search engine will start at the top level of web applications, and that is what is entered in the default "Local SharePoint Sites" content source. However, you will want to manually enter the other site collections in this content source since you cannot crawl anything at that top level. I don't know if this is the exact issue you are facing, but it was definitely the root of my problem and this error was what was displayed instead of something indicating that there was no content to be crawled.

share|improve this answer
    
Thanks Lori. No luck with this solution. Your help is appreciated. –  Frank O'Donnell Aug 11 '11 at 11:03

To access the web app while crawling, you need the following to be setup:

  • the default zone is always crawled
  • ntlm authentication is used.
share|improve this answer
    
Where exactly os the zone & security NTLM configured within the search admin? The farm is currently NTLM, I plan to configure kerberos at a later date. Thanks –  Frank O'Donnell Aug 11 '11 at 11:05
    
you don't configure NTLM & zone access in the search admin. That's configured in the web app settings. –  Bas Lijten Aug 11 '11 at 15:39
    
Hi Bas. The default zone is set with Full Read permissions. –  Frank O'Donnell Aug 16 '11 at 11:06
    
Full read permissions for the default access account too? –  Bas Lijten Aug 16 '11 at 15:13

Restart your server... for me it helps me ;)

share|improve this answer
3  
While this post may answer the question, we prefer more details such as "why" (e.g. after disabling loopback check you need to restart). Please edit your post with additional details. See How to Answer (sharepoint.stackexchange.com/questions/how-to-answer) for general guidelines. –  SPDoctor Mar 13 '12 at 15:43

If you are still getting access denied error after Disabling loopback check, make sure that you have given the Default Content Access account "Retrieve People Data for Search Crawlers" permissions. (From Manage Service Applications Page, select UserProfile Service Application and click on Administrators to view this setting)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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