none
Cannot access SharePoint 2013 publishing site

    Question

  • HI,

    I set up a SharePoint 2013 and everything seemed to work fine (setup was basically done using the codeplex autoinstaller script).

    But now I detected, that I have an issue with the publishing feature. Regardless of whether I activate this feature on an existing site collection or whether I create a new site collection with the Publishing Portal template, I cannot access the site. Even not with the site collection administrator account.

    I tried to assign the Central-Admin app-pool to the website (found this hint several times), but it doesn't solve the issue.

    In the ULS logs, I found the following:

    SPRequest.GetAclForScope: UserPrincipalName=i:0).w|s-1-5-21-3951779234-2814364508-2306989609-1113, AppPrincipalName= ,bstrWebUrl=http://krom.devnet.local/sites/pub ,guidScopeId=dff5401d-7fa6-4868-bcfe-ece146d7e275 ,fRequirePermissionCheck=True

    System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)), StackTrace:    at Microsoft.SharePoint.SPReusableAcl..ctor(SPRequest request, String webUrl, Guid scopeId, Boolean requirePermissionCheck)     at Microsoft.SharePoint.Publishing.AclCache.GetAclForScope(Guid scopeId, Boolean disposeOfSite)     at Microsoft.SharePoint.Publishing.WebControls.ConsoleXmlUtilities.ConfigurationXml(String configProvider, Boolean isBuiltInConfigFile)     at Microsoft.SharePoint.Publishing.WebControls.ConsoleXmlUtilities.GetConsoleNodeCollection(String configXml, ConsoleNode prePopulatedRootNode)     at Microsoft.SharePoint.Publishing.WebControls.ConsoleXmlUtilities.GetConsoleNodeCollectionFromXmlFile(String configName, Boolean isBuiltInConfigFile)     at Mi...
    ...crosoft.SharePoint.Publishing.WebControls.XmlConsoleDataSource.LoadTreeFromConfigXml()     at Microsoft.SharePoint.Publishing.WebControls.XmlConsoleDataSource.OnLoad(EventArgs e)     at Microsoft.SharePoint.Publishing.WebControls.PublishingSiteActionsMenuCustomizer.OnLoad(EventArgs e)     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Control.LoadRecursive()     at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfte...
    ...rAsyncPoint)     at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     at System.Web.UI.Page.ProcessRequest()     at System.Web.UI.Page.ProcessRequest(HttpContext context)     at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()     at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)     at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)     at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)     at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNo...
    ...tificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)     at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr native...
    ...RequestContext, IntPtr moduleData, Int32 flags)  

    Access Denied. Exception: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)), StackTrace:   at Microsoft.SharePoint.Library.SPRequestInternalClass.GetAclForScope(String bstrWebUrl, Guid guidScopeId, Boolean fRequirePermissionCheck, Object& pvarAcl, UInt64& lAnonymousMask)     at Microsoft.SharePoint.Library.SPRequest.GetAclForScope(String bstrWebUrl, Guid guidScopeId, Boolean fRequirePermissionCheck, Object& pvarAcl, UInt64& lAnonymousMask).

    Exception in file C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Template\Layouts\EditingMenu\SiteAction.xml: Thread was being aborted.

    Any ideas, what causes this issue and how to solve it?

    Thanks!!

    Monday, November 19, 2012 11:18 AM

All replies

  • Check to see if the SuperUser and SuperReader accounts were configured for the site.  I've seen this symptom before on publishing sites where they weren't configured.  The user has access to the site, but can't access the cached version of the site and therefore gets an access denied.

    These accounts are normally configured by AutoSpInstaller, but check to make sure they are there and configured.  The following post has information on how to check:

    http://sharepointrelated.com/tag/superuser/


    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Monday, November 19, 2012 1:28 PM
  • Hi,

    thanks for your reply - I checked the accounts and to me it seems to be ok:

    PS C:\Users\administrator> Get-SPWebApplication | %{Write-Host "Web Application:
     " $_.url "`nSuper user: " $_.properties["portalsuperuseraccount"] "`nSuper read
    er: " $_.properties["portalsuperreaderaccount"] "`n"}
    Web Application:  http://krom.devnet.local:8080/
    Super user:  i:0#.w|DEVNET\SP_CacheSuperUser
    Super reader:  i:0#.w|DEVNET\SP_CacheSuperReader

    Web Application:  http://krom.devnet.local/
    Super user:  i:0#.w|DEVNET\SP_CacheSuperUser
    Super reader:  i:0#.w|DEVNET\SP_CacheSuperReader

    They have been configured by AutoSPIntaller script. 

    Can I check something anything else regarding these users? Do they require special permissions, need to be in special groups?

    Thanks

    Monday, November 19, 2012 1:53 PM
  • If they were configured by AutoSpInstaller then they should be right as long as they were applied. 

    Are you using any custom Apps on the site?  In looking through your error message it looks like permissions for one of the Apps on the page is failing.


    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Monday, November 19, 2012 2:12 PM
  • No, I created the sub site from central admin and after creation succeeded was never able to access it - so no custom apps there. This only happens, if I create the site collection with publishing portal template - team site template for example works fine.

    I took a look into the IIS log and found the following:

    2012-11-19 14:24:33 fe80::55a3:a2df:7e9d:eb59%12 GET /_layouts/15/user.aspx obj={C701B918-B686-42B4-B1C5-B68FA4B2419F},doclib&list={C701B918-B686-42B4-B1C5-B68FA4B2419F} 80 0#.w|devnet\administrator fe80::55a3:a2df:7e9d:eb59%12 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.2;+WOW64;+Trident/6.0;+.NET4.0E;+.NET4.0C;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729) - 302 0 0 104
    2012-11-19 14:24:33 fe80::55a3:a2df:7e9d:eb59%12 GET /_layouts/15/AccessDenied.aspx Source=http%3A%2F%2Fkrom%2Edevnet%2Elocal%2Fsites%2Fpub%2F%5Flayouts%2F15%2Fuser%2Easpx%3Fobj%3D%7BC701B918%2DB686%2D42B4%2DB1C5%2DB68FA4B2419F%7D%2Cdoclib%26list%3D%7BC701B918%2DB686%2D42B4%2DB1C5%2DB68FA4B2419F%7D&Type=list&name=%7B1AC4E1A1%2D0C23%2D4203%2D96A2%2D419EC36CFDAD%7D 80 0#.w|devnet\administrator fe80::55a3:a2df:7e9d:eb59%12 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.2;+WOW64;+Trident/6.0;+.NET4.0E;+.NET4.0C;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729) - 200 0 0 30

    The list that is mentioned in the source-URL (ID starts with C701B918) is the Pages list - I checked this in SharePoint Designer. So it seems that I have no access to the Pages library and that would explain why I can't access the page..

    But why do I not have permission? And: how can I fix this? I tried the following powershell script but still no access to the pages library.

    PS C:\Users\administrator> $web = get-spweb http://krom.devnet.local/sites/pub
    PS C:\Users\administrator> $account = $web.ensureuser("devnet\administrator")
    PS C:\Users\administrator> $role = $web.RoleDefinitions["Contribute"]
    PS C:\Users\administrator> $list = $web.lists["Pages"]
    PS C:\Users\administrator> $list.breakroleinheritance($true)
    PS C:\Users\administrator> $assignment = new-object microsoft.sharepoint.sproleassignment($account)
    PS C:\Users\administrator> $assignment.roledefinitionbindings.add($role)
    PS C:\Users\administrator> $list.roleassignments.add($assignment)
    PS C:\Users\administrator> $list.update()
    PS C:\Users\administrator> $web.dispose()

    I also cannot change permission with SharePoint Designer because it just tries to open the related SharePoint page in browser and exactly is what I'm not allowed to do :-(

    Monday, November 19, 2012 2:31 PM
  • Got it - at least how to work around it! :-)

    I changed the permission of group "Style Resource Readers" to "Full Control" and after this I'm able to access the site.

    But I would like to know why this issue occurs because giving Style Resource Readers full control would not be a solution on a production environment.

    I will try to reproduce the workaround by creating a new publishing site...

    Monday, November 19, 2012 2:40 PM
  • Ok - it is reproducable.

    I create a new site collection with the Publishing Portal template. As before I was not able to access the site.

    I then changed the permission of group "Style Resource Readers" to "Manage Hierarchy" (Full control is not required). After this change the site is accessible.

    So I know how to fix the issue - but I do not know whether I have other side-effects due to incorrect site creation that may be visible later...

    Any ideas on this?

    Monday, November 19, 2012 2:48 PM
  • When you create the new site collection are you making yourself the site collection admin of the site?  If not, where have you added the admin userid to give it permissions in the site collection?

    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Monday, November 19, 2012 10:04 PM
  • Yes, I make myself site collection administrator. I can access the site in SharePoint Designer without any problem and I have permission to do what I want as long as it is inside SharePoint Designer and not in the browser.

    All that seems to be missing is the "Manage Hierarchy" permission for the "Style Resource Readers" group. Once this is set (in Designer), everything works fine.

    • Proposed as answer by Sridhar1983 Sunday, August 11, 2013 6:00 PM
    Tuesday, November 20, 2012 1:42 PM
  • Strange.  I've done several sites in 2013 with Publishing turned on and had no problems.  Glad you found a work around.  I can't explain why its happening to you.

    Paul Stork SharePoint Server
    MVP Principal Solutions Architect: BlueChip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Tuesday, November 20, 2012 7:31 PM
  • Anyone found a solution to this problem? Or is the workaround the only way ?

    sridhar

    Sunday, August 11, 2013 5:37 PM
  • One of my clients running into the same issue.  In the default configuration the Style Resource Readers group contains Everyone.  I don't think you want to give everyone the ability to manage hierarchy!  Also, although this does get the site back some things like navigation are broken for my client.

    My client is configured to use claims with Kerberos and everything was humming along fine until the content database was restored from backup.  Deleting the web app and recreating it fixes the problem for an hour or so.  IISResets or reboots were fixing it for a while but now have no effect.

    Anybody have a clue as to what this might be?  Distributed Cache is healthy.  SuperUser and SuperReader are configured for the webapps.

    Thursday, June 26, 2014 2:33 AM
  • I've just done a trial Disaster Recovery to a new farm and got exactly this issue.  I checked the super user accounts and they were reported correctly by PowerShell BUT checking the Web Application User Policies they were not correct see http://technet.microsoft.com/en-us/library/ff758656(v=office.15).aspx.

    The solution is simple enough just refresh the cache accounts for the web applications and this will set the user policies correctly.

    In PowerShell it would be:

    $PortalWebApplication = Get-SPWebApplication -Identity "Portal"

    $PortalWebApplication.Properties["portalsuperuseraccount"] = "DOMAIN\SP_CacheSuperUser"

    $PortalWebApplication.Properties["portalsuperreaderaccount"] = "DOMAIN\SP_CacheSuperReader"

    $PortalWebApplication.Update()

    Then try and acces it an voila!

    Wednesday, November 12, 2014 5:20 PM