locked
SharePoint 2010 - Crawl Fails - Access is denied RRS feed

  • Question

  • Please help!!  I have recreated the Search Service Application and when I try to do any type of crawl - I get the following error.  I can not figure out where the problem is.  The event logs indicate the same error as well.  I think it should be pretty straight forward.  I have already disabled the loopBackCheck in the registry.

    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.

    Please help!  Thank you.

    Walid

    Tuesday, October 5, 2010 10:42 PM

Answers

  • Months later, I found this thread while searching for solutions to the same error...  On Amazon Web Services I've setup an EC2 "all-in-one" VM for SharePoint 2010 testing and a www site staging.  "All-in-one" = Active Directory, SQL Server and SharePoint, etc. running locally on a single VM.

    The same base image had been working well for search, etc. when I decided to create an internet-accessible site and search that.

    While my server viewed the world as a local AD domain with 10.x.x.x net addresses, I had created a new Web Application with the default host header and root site collection as "http://hostname.internet-domain.com" (the Internet DNS name for the Internet-accessible Amazon EIP address).  Everything seemed to be working as expected until I initiated a crawl to that content source where the internet DNS host URL was used as the target.  "Access denied..." error for the default SPFarmAcc crawl entity!

    This thread's talk of a crawl connection path via an http proxy made me wonder...  I saw that a ping to my Web Application host name targeted the external Internet-accessible address rather than the default local interface (The AWS EC2 VM gets a new random 10.x.x.x IP address with each boot).  AWS' externally-accessible IP addresses are called "Elastic IP addresses", and are mapped to deliver traffic to your associated VM, but the address doesn't actually belong to a local interface.  Anyway, I fooled my server into seeing the internet domain name as a local IP address by adding a line to the local hosts file.  Now, a ping to the Web Application URL hits a local IP address (I had setup a Microsoft loopback adapter in order to have a static IP address for the local AD+DNS).

    Crawl worked after this! 

    Sunday, September 11, 2011 10:38 PM
  • bgmeek,

    Thank you so much for your post and sorry for the late reply; it's been busy!  The host file solution did the trick.  In my case I could browse the site from the search server or any other WFE but search would fail.  As soon as I created the entries in the hosts file to point DNS names to the local host, search (I mean crawl) started to work.

     

    Walid


    Walid Gharwal
    • Edited by WalidG Friday, October 14, 2011 4:38 PM
    • Proposed as answer by Pratik Vyas Thursday, June 20, 2013 6:59 AM
    • Marked as answer by Pratik Vyas Thursday, June 20, 2013 6:59 AM
    Friday, October 14, 2011 4:38 PM

All replies

  • Try changing the default account to a site collection admin and try running the search again. If it fails then something is wrong with your search service.
    Vr,
    SharePointNinja
    Wednesday, October 6, 2010 3:47 AM
  • Hi Walid,

    This error is primarily caused by the Default Content Access Acount not having access to the content you're trying to crawl. Make sure that the account has a Read access to the Content (Sharepoint site, Web site etc...).

    You can also try to add a crawl rule to the site you're trying to crawl and specify a different Content Access Account.

    Thanks,

    Dennis

    Wednesday, October 6, 2010 3:55 AM
  • Your default content access account should be listed in Central Administration -> Manage Web Applications -> Choose a web application -> click User Policy.  On that screen verify that your content access account is listed with Full Read permissions.  Whatever, you do, do not change to a content access account that has administrator privileges.
    Corey Roth blog: www.dotnetmafia.com twitter: @coreyroth
    Wednesday, October 6, 2010 2:16 PM
  • Hi, take a look at this-

    http://www.aaron-rendell.co.uk/blog/_archives/2010/1/30/4442814.html

    Hopefully this will help.


    Regards | Aaron www.aaron-rendell.co.uk | SharePoint Consultant | Microsoft Gold Partner - Silversands, Poole, Dorset, England
    Wednesday, October 6, 2010 2:22 PM
  • Why is this necessary?  The search will crawl the entire web/app and the default content access account has full read permission on the web/app.


    Walid Gharwal
    Wednesday, October 6, 2010 4:00 PM
  •  

    Hi and thanks.  My Default content Access Account has access and I have verified that.  Is a crawl rule necessary to get this working?


    Walid Gharwal
    Wednesday, October 6, 2010 4:02 PM
  •  

    Corey, As I have replied to Dennis earlier.  This permission is already in place.  I am really running out of options here.

     

    Thanks.


    Walid Gharwal
    Wednesday, October 6, 2010 4:04 PM
  • Thanks but I have already have already disabled the loopBackCheck in the registry.  I still have the issue.
    Walid Gharwal
    Wednesday, October 6, 2010 4:16 PM
  • Did you convert this web applicatin from classic authentication to Claims based? I've had that cause this same issue.

    Can you log into the server running search as the content crawl account and try to hit the web applications? What happens?

    tk


    SharePoint MVP My blog/a> My SharePoint 2010 Admin book: Professional SharePoint 2010 Administration
    Wednesday, October 6, 2010 9:35 PM
  • Todd,

    Thank you for responding.  No, I have not converted this web app from classic to Claims. 

    I can access the site using the crawl acount when I sign in to the site as that user.  I can not RDP to the server as this user does not have remote access to server.  Also, I would like to add that the crawl account and the search service account are the same. 

    Crawl still fails.

     PS.  I own your book.


    Walid Gharwal
    Thursday, October 7, 2010 7:51 PM
  • I also have this problem(and Todd's book).

    Brand new environment. Default Service Account has access to all sharepoint sites, crawl rules established, and service account set up with Full Read on web application.

    I even created a new Search Service Application and tried to crawl my sites, same result.

    "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."

    Has anyone solved this yet?

    Friday, October 22, 2010 2:47 PM
  • I still have the same issue.  I have looke at the ULS logs, event logs, recreated the Searh Service App, verified accounts have FULL Read access to the Web Applications.  I dont' know where to go from here.
    Walid Gharwal
    Friday, October 22, 2010 4:16 PM
  • Just to test - even after giving FULL CONTROL access to the default content access account - I get the same error and crawl fails.
    Walid Gharwal
    Friday, October 22, 2010 8:00 PM
  • Perhaps the problem is that the crawl accounting is not associated with the content databases?  I understand that from within SharePoint you gave the crawl account full read to the web application.  However, if you check SQL Server does your crawl account have proper access to the content datbase(s)?  Use SQL Server Management Studio to which databases the crawl account has access too.
    Dennis Bottjer | Follow Me: @dbottjer | Blog: Dennis Bottjer.com
    Sunday, October 24, 2010 4:23 AM
  • I recently came across a very similar problem. In my case users had a proxy configuration  (.pac) file which forced most traffic to go through the proxy (authenticated). I was getting http status 200  in the iis logs from the crawler but the search would fail everytime with access denied. After trying several differnent combinations of Alternate access mappings and host file entries i still wasnt having any success. In the end i used Netmon to capture the traffic from the crawler and found that it was indeed trying to use a proxy (it seemed to be using the pac file) my workaround was to specify a proxy in the search service application and then specify the content source adresses in the bypass list in an attempt to force search to connect directly. It took a bit of tweaking but eventually i could see search connecting directly to the server rather then through the proxy (using netmon).

    Hope this helps

    Tim

    Wednesday, October 27, 2010 12:25 AM
  • This was actually a very good try as we do use .pac files.  However, the site is a loca intranet site and it wasn't going through the proxy.
    Walid Gharwal
    Tuesday, November 2, 2010 4:10 PM
  • How did u fix your issues ... and please tell me you didnt recreate the web app from scratch :D
    Thursday, November 4, 2010 4:58 AM
  • A further update to my earlier post.

    In the end i resolved my issue by running internet exporer as the search service(using runas) the "automatically detect settings" option was checked under lan settings. Unchecking this resolved my issues.

    Netmon was the key for me. I would recomend using it for any others encountering the problem, after you have ruled out permissions.

    Tim

    Tuesday, November 9, 2010 4:02 AM
  • I had the same access denied issues.

    I tried everything I could think of (disable loopback, granting full control permissions, manually granting full read permissions on the database, changing the web application to anonymous access, creating crawl rules to crawl as http, etc.) and after reading your post (TLeyden) it lead me to the ultimate problem that I had which was with the proxy.

    I had a proxy configured with my search service application so that it could crawl my company's external www site. What was happening was that, using a FQDN, it was thinking that my webapp1.company.corp.com sharepoint address was an external site, and trying to go out the proxy (which of course wouldn't get you anywhere). After putting in an exception into the proxy address, BAM! it worked as expected.

    Thanks for saving me dozens of more hours of hair pulling!

    Wednesday, June 15, 2011 11:38 PM
  • Months later, I found this thread while searching for solutions to the same error...  On Amazon Web Services I've setup an EC2 "all-in-one" VM for SharePoint 2010 testing and a www site staging.  "All-in-one" = Active Directory, SQL Server and SharePoint, etc. running locally on a single VM.

    The same base image had been working well for search, etc. when I decided to create an internet-accessible site and search that.

    While my server viewed the world as a local AD domain with 10.x.x.x net addresses, I had created a new Web Application with the default host header and root site collection as "http://hostname.internet-domain.com" (the Internet DNS name for the Internet-accessible Amazon EIP address).  Everything seemed to be working as expected until I initiated a crawl to that content source where the internet DNS host URL was used as the target.  "Access denied..." error for the default SPFarmAcc crawl entity!

    This thread's talk of a crawl connection path via an http proxy made me wonder...  I saw that a ping to my Web Application host name targeted the external Internet-accessible address rather than the default local interface (The AWS EC2 VM gets a new random 10.x.x.x IP address with each boot).  AWS' externally-accessible IP addresses are called "Elastic IP addresses", and are mapped to deliver traffic to your associated VM, but the address doesn't actually belong to a local interface.  Anyway, I fooled my server into seeing the internet domain name as a local IP address by adding a line to the local hosts file.  Now, a ping to the Web Application URL hits a local IP address (I had setup a Microsoft loopback adapter in order to have a static IP address for the local AD+DNS).

    Crawl worked after this! 

    Sunday, September 11, 2011 10:38 PM
  • bgmeek,

    Thank you so much for your post and sorry for the late reply; it's been busy!  The host file solution did the trick.  In my case I could browse the site from the search server or any other WFE but search would fail.  As soon as I created the entries in the hosts file to point DNS names to the local host, search (I mean crawl) started to work.

     

    Walid


    Walid Gharwal
    • Edited by WalidG Friday, October 14, 2011 4:38 PM
    • Proposed as answer by Pratik Vyas Thursday, June 20, 2013 6:59 AM
    • Marked as answer by Pratik Vyas Thursday, June 20, 2013 6:59 AM
    Friday, October 14, 2011 4:38 PM
  • Another thing to try is to restart the Sharepoint Server Search Service. 

    I had similar symptoms when creating a new content source that referenced a new file server.  I verified the Default content access account had the correct permissions (and it had been crawling other content sources for several years without issue). 

    Eventually restarting the Sharepoint Server Search Service and starting another full crawl resolved the problem.

    Wednesday, April 3, 2013 9:08 PM
  • is that right? Isn't any access to the data in SQL server via the website application pool identity? It's not like every user of Sharepoint has any access rights on SQL server.
    Sunday, September 3, 2017 5:51 PM