I have a site collection with several subsites which I can no longer access.  I am listed as both a farm administrator and site collection administrator in this installation.  I can access a separate site collection on the same web application, and I can access the Central Administration site.  All accounts including mine, get an access denied error when navigating to any site on the aformentioned site collection.

I was not having any access issues until this morning when I was doing some housekeeping and changing group membership at the root site level, and also deleting a few custom sharepoint groups that were no longer needed.  At some point after deleting one of these custom groups, I began getting the access denied errors.

I found the error below in the uls viewer, but haven't seen anything that looks related in the windows application log.  I had some similar issues yesterday, but was able to resolve them by toggling Inherit Permissions, Stop Inheriting permissions from a subsite using SharePoint Designer.  I've had no such luck with SharePoint Designer today.  I've scoured this forum and the web for a solution, but have not found any issue that looked the same as mine.  Any help would be appreciated.

PortalSiteMapProvider was unable to fetch children for node
 at URL: /, message: Thread was being aborted., stack trace:  
 at System.Threading.Thread.AbortInternal()   
 at System.Threading.Thread.Abort(Object stateInfo)   
 at System.Web.HttpResponse.End()   
 at Microsoft.SharePoint.Utilities.SPUtility.Redirect(String url, SPRedirectFlags flags, HttpContext context, String queryString)   
 at Microsoft.SharePoint.Utilities.SPUtility.RedirectToAccessDeniedPage(HttpContext context)   
 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context)   
 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)   
 at Microsoft.SharePoint.Library.SPRequest.GetSubwebsFiltered(String bstrParentWebUrl, UInt64 iPermMaskForUnique, UInt64 iPermMaskForInherited, Int32 nWebTemplate, Int16 nProvisionConfig, Int32 lToLinkRecurringMeeting, Object& pvarSubwebs, Object& pvarSubwebIds, Object& pvarLangs, Object& pvarTitles, Object& pvarDescriptions, Object& pvarCreationTimes, Object& pvarModifiedTimes, Object& pvarUserIsWebAdmins, Object& pvarWebTemplates, Object& pvarProvisionConfigs, Object& pvarMeetingCounts)   
 at Microsoft.SharePoint.SPWeb.SPWebCollectionProvider.GetWebsData(String[]& strNames, String[]& strServiceRelUrls, Guid[]& guidWebIds, Int32[]& nLanguages, String[]& strTitles, String[]& strDescriptions, String[]& strCreationTimes, String[]& strModifiedTimes, Boolean[]& bUserIsWebAdmins, Int32[]& nWebTemplates, Int16[]& nProvisionConfigs, Int16[]& nMeetingCounts, Int32[]& nUIVersions, Int32[]& nFlags, String[]& strMasterUrls, String[]& strCustomMasterUrls)   
 at Microsoft.SharePoint.SPWebCollection.EnsureWebsData()   
 at Microsoft.SharePoint.SPWebCollection.get_WebsInfo()   
 at Microsoft.SharePoint.Publishing.Navigation.PortalWebSiteMapNode.FetchDynamicItems(PublishingWeb pubWeb, NodeTypes includedTypes, Boolean& websFetched, Boolean& pagesFetched)   
 at Microsoft.SharePoint.Publishing.Navigation.PortalWebSiteMapNode.PopulateNavigationChildrenInner(NodeTypes includedTypes)   
 at Microsoft.SharePoint.Publishing.Navigation.PortalWebSiteMapNode.PopulateNavigationChildren(NodeTypes includedTypes)   
 at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode.GetNavigationChildren(NodeTypes includedTypes, NodeTypes includedHiddenTypes, Boolean trimmingEnabled, OrderingMethod ordering, AutomaticSortingMethod method, Boolean ascending, Int32 lcid)   
 at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode.GetNavigationChildren(NodeTypes includedTypes, NodeTypes includedHiddenTypes, OrderingMethod ordering, AutomaticSortingMethod method, Boolean ascending, Int32 lcid)   
 at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode.GetNavigationChildren(NodeTypes includedHiddenTypes)   

I should also mention that I am using SharePoint 2010.  I have also already cleared the SharePoint configuration cache since this error began.

I would reset the site collection administrator using powershell.

http://www.powershell.nu/2009/02/13/set-folder-permissions-using-a-powershell-script/

Here is a link showing how to assign permissions.  It sounds like they were lost while you were making your changes.

I have other posts on this topic which you can see as well.

http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/a19bc915-0a2a-41da-b078-cdfdbd82f798/

Good luck,

Gary

Hi Gary.  I am still able to access the Central Admin site, and can see that I am still listed as primary site collection administrator.  I have also added a user policy to the containing web application giving me full control.  On your suggestion, I also tried using the powershell just now to run the following command to make me secondary site collection owner:

Set-SPSite -Identity "<SiteCollection>" -SecondaryOwnerAlias "<User>"

This didn't seem to help either.  Your powershell link discussing updating the ACL of some folders using powershell.  Were you suggesting that I used powershell to update the ACL of some folders?  if so, which folders do I need to update?

I was able to resolve this by deleting the existing web application in the Central Administration web application and choosing to delete the IIS web app, and NOT deleting the associated content database.  I then created a new web application in Central Administration and associated with the old content database.  Voila!  I can now access the newly created web app with all my old content. 

• Marked as answer by It's Complicated Wednesday, May 04, 2011 6:28 PM

Hi folks,

 

We also have seen this behaviour a couple of times with different web applications. For no reason what so ever all of a sudden a site collection administrators (or owners etc) cannot login. The user logs in with his or her credentials and gets a nice sharepoint page telling that he or she has to logon with credentials that are authorised. Even if the user is a site collection administrator in the central administation for the specific web application. The only solutions is indeed to delete the webapplication from the central administration and leaving the content database intact and recreating the webapplication.

 

Aldo this is no garantee because we've seen the issue appear again some time later with the same fixed application. This sounds like a bug aldo we can't find a reason why its happening.

So this isn't a permanent solutions but a workaround in my opinion.

 

Regards,

 

Reinout Pennings

I was able to resolve this by deleting the existing web application in the Central Administration web application and choosing to delete the IIS web app, and NOT deleting the associated content database.  I then created a new web application in Central Administration and associated with the old content database.  Voila!  I can now access the newly created web app with all my old content. 

This doesn't seem like a resolution to me, i understand that deleting the web application and not the content database may resolve the issue, but that seems like using a sledgehammer for a nail.  when you're dealing with production environments, deleting the web application isn't really an option.

Anyway, i had this same issue when a client asked me to remove all the users from a SP permissions group as we were decommisioning the site.  The group i removed from the SP permissions group was corp\all users, something like that.  As soon as I did that, I couldn't even log into the site. And I was a site collection admin, and I even went as far as to add myself to the web app policy under Full Control, still nothing. 

So i did some research and found the sledgehammer advice, which i wasn't looking forward to doing.  there are simply too many customizations, binding configurations to justify deleting the web app.  So i took a look around, i tried to access the site settings directly by going to http://server/_layouts/settings.aspx and it worked.  I couldn't access any of the links on the page without getting the access denied error, that is, except for site collection administrators.  So I added the superuser account to site collection administrators and it worked.  i'm back in. 

So i guess the moral of the story is, if you can hit the _layouts/settings.aspx page, it probably has something to do with the cache accounts.  Start looking there.

• Edited by Autechre11 Wednesday, January 18, 2012 5:27 PM
• Proposed as answer by Autechre11 Wednesday, January 18, 2012 5:28 PM

This behavior happens when you've incorrectly configured the object cache user accounts and then enabled the claims authentication.  The reason the delete and recreate of the application works is because you're reseting these values.

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

The default Portal Super Reader account is NT Authority\Local Service, which is not correctly resolved in a claims authentication application. As a result, if the Portal Super Reader account is not explicitly configured for a claims authentication application, browsing to site collections under this application will result in an “Access Denied” error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.

The reason going the the settings.aspx works is because of how _layouts is handled.  Article referenced above has steps on how to set these accounts properly.

• Proposed as answer by StevenJones Tuesday, January 31, 2012 7:51 PM

This behavior happens when you've incorrectly configured the object cache user accounts and then enabled the claims authentication.  The reason the delete and recreate of the application works is because you're reseting these values.

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

The default Portal Super Reader account is NT Authority\Local Service, which is not correctly resolved in a claims authentication application. As a result, if the Portal Super Reader account is not explicitly configured for a claims authentication application, browsing to site collections under this application will result in an “Access Denied” error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.

The reason going the the settings.aspx works is because of how _layouts is handled.  Article referenced above has steps on how to set these accounts properly.

I saw that post as well, in my case I had not enabled Claims.

I am having the same issue for SharePoint 2007, is there a way I can do the same for SP 2007 that is recommended in this post from above?

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

We just experienced this issue on a client's production server. I was quite leery of killing the web app and re-creating it, but in the end found another blogger's advice to check the user policy permissions for that web application, and one simple addition did the trick: re-adding "NT AUTHORITY\authenticated users" to have READ access to the app cleared everything up. We still are not sure how that policy was zapped, but it was likely during some backup the previous evening.

Here's his blog entry. We had tried almost everything up until the last step: http://www.go4sharepoint.com/Forum/access-denied-everyone-even-site-24358.aspx

• Proposed as answer by N_e_a_l_M Saturday, February 23, 2013 3:36 PM

Make sure you give  supper user account with following format.

Moral of the story: if you are in claims mode, you will need to use the claims user name (i:0#.w|domain\user).

some one point out that.

http://blogs.msdn.com/b/andrasg/archive/2010/09/30/setting-the-super-user-account-on-sharepoint-2010-and-getting-access-denied-errors-afterwards.aspx

This solved my problem; thank you!

You saved me (I solved my problem)

Thank you so much

check whether the content DB is set to read-only mode. if it is in read only change it to "not locked" mode.

Please read the post for more details: http://bit.ly/1MRKdhN 

Regards,
Sasi Kumar Reddy

• Proposed as answer by sharepointquicksolutions.blogspot.in 2 hours 34 minutes ago

check whether the content DB is set to read-only mode. if it is in read only change it to "not locked" mode.

Please read the post for more details: http://bit.ly/1MRKdhN 

Regards,
Sasi Kumar Reddy

• Proposed as answer by sharepointquicksolutions.blogspot.in 2 hours 26 minutes ago