SharePoint Products TechCenter > SharePoint Products and Technologies Forums > SharePoint - Search > "Access is denied. Check that the Default Content Access Account has access to this content"
Ask a questionAsk a question
 

Answer"Access is denied. Check that the Default Content Access Account has access to this content"

  • Monday, May 21, 2007 12:01 PMPatrik Luca Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Our search is not working. The crawl log indicates following error: "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)".

     

    If I check the event viewer, it indicates following error: "Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. [CLIENT: <local machine>]"

     

    My default content access account is another one than this NT AUTHORITY\NETWORK SERVICE account. The content access account password is correct. Apparently this content access account is translated to the NETWORK SERVICE account upon a crawl. And this network service account doesn't has the appropriate rights on database level. How can I fix this?

     

    • Edited byMike Walsh MVPMVP, ModeratorTuesday, April 07, 2009 8:11 AM" " added around the error message (to make it clear this IS an error message
    •  

Answers

  • Friday, April 03, 2009 9:46 PMelpollodiablo Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Had this problem and solved it by using user@domain.local instead of domain\user when specifying the Default Content Access Account. 

    Central Administration --> SSP --> Search Administration | Default Content Access Account.

    Still puzzled as to why this cropped up at all.  Crawl logs say that crawls were successful as of a week ago.  Then suddenly it stopped.  No changes were made (I only touch this machine to do backups and apply any patches, which is rare).  (The patch part is rare, not the backup part.)

    HTH
  • Monday, May 21, 2007 5:57 PMStefan Keir Gordon Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    I had a post in my Blog about this that might help you. It was targeted at BDC crawling, but should apply to you also.

    http://www.keirgordon.com/2007/04/bdc-crawl-error-parameter-is-incorrect.html


    You can change that default content access account in the search settings for your shared service provider.

    Keep in mind that whatever account you choose to crawl with, you will need to add it to your SQL server with permissions.


All Replies

  • Monday, May 21, 2007 5:57 PMStefan Keir Gordon Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    I had a post in my Blog about this that might help you. It was targeted at BDC crawling, but should apply to you also.

    http://www.keirgordon.com/2007/04/bdc-crawl-error-parameter-is-incorrect.html


    You can change that default content access account in the search settings for your shared service provider.

    Keep in mind that whatever account you choose to crawl with, you will need to add it to your SQL server with permissions.


  • Tuesday, September 11, 2007 9:18 AMsnehal parkar Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    check ur default access account has the permission to crawl or not first i don't think so NT AUTHORITY\NETWORK SERVICE  is the account should be used. try with the account in default content access account on which ur servcies of moss are running i mean office sharepoint servcies search or check with the administrator account also to crawl.u might get it.cheers up Smile

  • Thursday, September 04, 2008 6:48 PMMichaelinSyracuse Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I'm also working through this.  Have found many posts but no solution.  I've verified that the account has proper permissions and that both the Default Content Access Account and the account used to run the Office Sharepoint Server Search are the same.  Now I've got a new error which I can find no information on "The password for the content access account cannot be decrypted because it was stored with different credentials. Re-type the password for the account used to crawl this content."

    Thoughts?

    Thanks,
    Michael
    mrw
  • Tuesday, September 23, 2008 3:37 AMdahiya Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    MichaelinSyracuse said:

    I'm also working through this.  Have found many posts but no solution.  I've verified that the account has proper permissions and that both the Default Content Access Account and the account used to run the Office Sharepoint Server Search are the same.  Now I've got a new error which I can find no information on "The password for the content access account cannot be decrypted because it was stored with different credentials. Re-type the password for the account used to crawl this content."

    Thoughts?

    Thanks,
    Michael


    mrw



    I was also getting the same error but was able to solve the problem by going back to the Search Settings page under SSP and then reentering the credentials for the content crawler account.
    Try if that works for you.

    Vivek
  • Thursday, October 09, 2008 9:55 PMT Foxhole Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    I am getting the same error on a document library... not a sub site or at the site collection level. THe main user is adding meta-data to each of the documents within this specific doc lib. i will say that the doc lib in questiosn does contain ALOT of folders. There are not stacked, maybe 2 levels deep at best. Could the folders be causing an issue? the user adding meta-data while it is crawling?

  • Tuesday, March 31, 2009 6:53 AMSandeep Lad Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer
    Hi all,

     

    The resolution for this was to add the following registry key

    1) Click Start, click Run, type regedit, and then click OK.
    2) In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    3) Right-click Lsa, point to New, and then click DWORD Value.
    4) Type DisableLoopbackCheck, and then press ENTER.
    5) Right-click DisableLoopbackCheck, and then click Modify.
    6) In the Value data box, type 1, and then click OK.
    7) Quit Registry Editor, and then restart your computer.

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

    ...Sandeep Lad

     

    • Proposed As Answer byHeliguyG6 Tuesday, May 12, 2009 2:03 PM
    •  
  • Tuesday, March 31, 2009 6:53 AMSandeep Lad Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer
    Hi all,

     

    The resolution for this was to add the following registry key

    1) Click Start, click Run, type regedit, and then click OK.
    2) In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    3) Right-click Lsa, point to New, and then click DWORD Value.
    4) Type DisableLoopbackCheck, and then press ENTER.
    5) Right-click DisableLoopbackCheck, and then click Modify.
    6) In the Value data box, type 1, and then click OK.
    7) Quit Registry Editor, and then restart your computer.

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

    ...Sandeep Lad

     

    • Proposed As Answer byPSeale Wednesday, April 01, 2009 6:14 PM
    •  
  • Wednesday, April 01, 2009 6:15 PMPSeale Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sandeep, today you're my hero, that worked!
  • Friday, April 03, 2009 9:46 PMelpollodiablo Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Had this problem and solved it by using user@domain.local instead of domain\user when specifying the Default Content Access Account. 

    Central Administration --> SSP --> Search Administration | Default Content Access Account.

    Still puzzled as to why this cropped up at all.  Crawl logs say that crawls were successful as of a week ago.  Then suddenly it stopped.  No changes were made (I only touch this machine to do backups and apply any patches, which is rare).  (The patch part is rare, not the backup part.)

    HTH
  • Tuesday, April 07, 2009 7:54 AMJ Siegmund [MCTS] Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Same here! I also noticed all search crawls suddenly stopped working. Used elpollodiablo's solution and now they seem to run again. CPU is spiking against the roof so there must be something happening :)

    Strange behaviour though, I updated the server yesterday with the latest Windows updates; perhaps those had something to do with this?
    MCTS in Web Application Development in .NET 2.0
  • Tuesday, April 28, 2009 4:37 AMawell Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi there,

    For some reason I'm always having authentication troubles with the search crawling in SharePoint.

    Some things I have noticed:

    1) The content access account doesn't need specific permissions in SQL server. Although somehow my SPSearch account (content access) ended up with sysadmin privleges. :S

    2) My latest troubles with the crawler seemed to be a direct result of installing KB963027 (supposedly a "cumulative update for IE7"). This same update caused all sorts of other issues with NTLM (I couldn't log in to any of my sharepoint sites at all - except central admin), so I had to make the DisableLoopbackCheck registry entry... Before entering this, search crawling was failing for ALL my local sharepoint sites except one (which seemed to be working only because I had some crawl rules set up for it) - as per Sandeep's post.

    3) Simply adding a crawl rule like "include http://site/*" fixed the problem for that site only.

    4) I tried elpollodiablo's solution, unfortunately sharepoint said the username was invalid when I entered it in that format.

    5) The problem seems to cause itself at random times, without any user input.


    My conclusion would be that the majority of people here are experiencing the same problems, due to windows updates. The same problems seem to be evident on multiple OSes, suggesting that it is some core component of NTLM which is at fault. the LSA loopback check thing (whatever the ____ that is!!?) seems to be the root cause, seemingly invalidating the "default content access account" setting in sharepoint. If the default content access account value is re-saved the problem seems to be fixed. Also adding a crawl rule seems to bypass the content access account problem, even if you have "use the default content access account" specified for the rule.

    The main issue here is the sheer unpredictability of the problem...!
    I really think Microsoft should do something to fix this. There's definitely a bug in there somewhere, and leaving the user to figure out what's going on isn't really acceptable..
  • Tuesday, April 28, 2009 10:03 PMStowner Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer
    Sandeep is the bomb!!!  Worked like a charm. 
    • Proposed As Answer byStowner Tuesday, April 28, 2009 10:39 PM
    •  
  • Thursday, April 30, 2009 12:54 PMFredrikLM Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hey!
    Your`e the man Sandeep.
    I spent weeks searching for solution, this worked.

    Fredrik
  • Friday, May 01, 2009 2:51 PMSteve03820 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    This issue was caused by the .NET Framework 3.5 SP1 & Family Updates, in that the authentication methods for communication between the specific SharePoint services were changed.  The DisableLoopbackCheck does in fact work, but I expect it will be the cause for additional headaches in the near future when additional Service Packs are released.

    For the time being, remember to make this change on all SharePoint Servers in your farms.  If not, you have additional problems, such as incredible latent pages, the application pools shutting down unexpectedly - yes...actually shutting down, and corrupting your content databases to the point that Content Deployment ad Quick Deploy will no longer work.

    Fun Stuff

    - Steve

  • Thursday, May 07, 2009 3:13 PMAndre Galitsky Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    We were getting the same error after the latest round of security patches:  "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)".

    Adding DisableLoopbackCheck registry value to all of our SharePoint farm servers fixed the issue.  No restart of services or machines was needed.
    Andre Galitsky, MS-Certified SharePoint Administrator, Minneapolis, MN -- My SharePoint Blog: http://www.sharepointnomad.com
  • Tuesday, May 26, 2009 3:28 AMthievesguild Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    This also fixed my SharePoint problem.  But it also caused RDC terminal server connections to be denied.  Anyone else experience this or have a fix?
  • Tuesday, May 26, 2009 1:52 PMBPulliam Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sandeep is indeed the man...Fixed

    Thanks much!
    • Edited byBPulliam Tuesday, May 26, 2009 1:52 PMspelling error
    •  
  • Monday, June 01, 2009 1:21 PMSemion Kras Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    You are my hero Sandeep Lad ,
    i spent 2 hours to fix this freaking error , it also fixes the problem to visit site from sharepoint server .

    Sem
  • Tuesday, June 09, 2009 2:14 AMNick Amiradaki Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sandeep, its true you are the man. I'll spread the word!

    Thank heaps, spent about 3 hours on this one prior to finding your post.

    How did you come across the loop back reg key as the fix?
  • Monday, June 15, 2009 8:21 PMBob Klass Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Indeed, Sandeep's solution worked. A reboot was not needed, but an IIS reset and reset the search service.

    Thanks. This stuff should not be happening.
  • Wednesday, July 01, 2009 4:30 PMFaizel Mootheril Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Thanks to Sandeep's solution. It worked like a charm...You are indeed a genius. This solution helped to resolve an emergency. I thank all of you who went through this before me to arrive at this solution and posting it online. Thanks Again to Sandeep and the rest.
  • Tuesday, July 28, 2009 1:02 PMHari2009 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi ,

    I am having the same error as"Our search is not working. The crawl log indicates following error: "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)"."

    I am having windows 2003 server with SP2 installed.
    My situation is.

    I have 2 web application in my SPP , one for production which is running for past 3 yrs and another one i created for testing by taking backup from PROD site & restore in new web application.

    When i search for some items in both site i can able to find the Test Site in my result and not able to see the Prod site.
    I got error saying crawl log indicates following error: "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)".

    Both the site is rrunning with same yuser access right but getting error only for Prod site.

    Pls help me.


    Regards,
    Hari


  • Wednesday, July 29, 2009 2:07 AMAndre Galitsky Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Hari:

    The first thing I'd do is to make sure that your Default Content Access account does indeed have access to the content.  Log in to your SharePoint site in Prod using this account and see if you can access the content via your browser.  This account needs at least Reader access in order to be able to index it. 

    I'd also suggest separating your Prod and Test environments.  If you can't set them up on separate instances of SharePoint, at the very least create separate SSPs for each environment.  You probably don't want your Prod users searching your Prod site and finding Test content.


    Andre Galitsky, MS-Certified SharePoint Administrator, Lexington, KY -- My SharePoint Blog: http://www.sharepointnomad.com
  • Wednesday, July 29, 2009 6:04 AMHari2009 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi Andre,

    Thanks a lot for your information.

    Sure i will create new SPP and associate my Test site with new SSP.

    Currently i dont know the password used for Default Content Access Account id so i am planning to create new user and assign it to Default Content Access account.

    Bcoz i took backup of Prod web application and restored in new Test web application just 5 days back and i can able to get search results from Test site but not from Prod site and getting Access Denied error only for my Prod site during Content Crawl.

    Pls let me know whether i need to create Domain account or local account for Search and where and all i need to set this new user id & pwd ?
    is it enough if i set new id & pwd in Default content access account page? or i need to set this in DB also?

    Kindly help me.

    Regards,
    Hari
  • Wednesday, July 29, 2009 8:43 PMAndre Galitsky Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Your Default Content access account must be a domain account.  Please review these resources for more information:

    http://technet.microsoft.com/en-us/library/cc678863.aspx

    http://technet.microsoft.com/en-us/library/cc263445.aspx

    http://support.microsoft.com/default.aspx/kb/934838

    As always, try all your configuration changes in Test first, before deploying in Production.

    You might also want to purchase a good SharePoint admin book for a thorough review of security practices and administration, such as this one:

    http://www.amazon.com/Microsoft%C2%AE-Office-SharePoint%C2%AE-Administrators-Companion/dp/0735622825


    Andre Galitsky, MS-Certified SharePoint Administrator, Lexington, KY -- My SharePoint Blog: http://www.sharepointnomad.com
  • Saturday, August 01, 2009 9:08 AMHari2009 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi Andre,

    Thanks a lot for information sharing.
    Will try changing the default access account and get back to you.


    Regards,
    Hari
  • Friday, August 21, 2009 7:34 PMKish B Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer

    Sandeep Your solution worked.

    Everyone,
       Cautious: Go thru the below link before you switch it on PROD environment.
    http://harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx

    • Proposed As Answer byKish B Friday, August 21, 2009 7:35 PM
    • Edited byKish B Monday, August 24, 2009 4:07 PM
    •  
  • Tuesday, September 22, 2009 6:08 AMdrewberrylicious Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    THanks Sandeep...

    I had the same problem and your post helped me resolve it.