SharePoint cat fixing them errors

Subsite creation in SharePoint fails with error 0x80070005 for any user (even global/farm admins!)

This post was most recently updated on August 26th, 2022.

4 min read.

This issue seems to pop up bafflingly often, so I thought that it was finally time to document it for future generations. Granted, it mainly considers Classic SharePoint (which is very tightly built around Publishing features) – but Classic is going to be part of our lives for quite a while still, especially for those of us still primarily on SharePoint Server!

While trying to provision subsites to your SharePoint Publishing intranet you encounter either a generic “Access Denied” -error or any error with 0x80070005 as the underlying error code. Your subsite is not created. This error might surface via the GUI, via PowerShell, using CSOM, or even in full-trust -code running in a farm solution.

Your permissions don’t seem to help at all – no matter which accounts you’re using, you get the same error.

Solutions

A lot of things could cause this – without getting access to more log information, the error is very ambiguous. However, a lot of times it’s related to the badly documented, built-in permissions that Publishing infrastructure requires. And those can usually be fixed, as long as you figure out what the actual issue is.

Let’s take a look at a few different solutions you could try and see if they help!

Fix the style/design resource permissions

In a lot of cases, this issue is thrown because someone messed around with the built-in SharePoint permissions. Let’s see how to fix that!

I was originally led to this solution from this blog, which seems to have been removed since then: https://savtechsol-public.sharepoint.com/Education/BeckysBlog/Lists/Posts/Post.aspx?ID=174. I guess that’s what you get for using SharePoint Online’s public-facing sites… :) 

Despite being removed, the blog post seems to be mirrored on this content-stealing website (not worth actually linking to them – stealing content is pretty bad-mannered): http[://]sptrac.com/wordpress/?p=3003

I think the blog post was originally posted by Becky Bertram. It says:

It turns out that the Restricted Readers group is natively assigned permission to several libraries in a Publishing Site Collection, such as the Master Page Gallery, the Site Collection Images, the Style Library, etc. (You can see what permissions the Restricted Readers group has by going to the View Groups page, selecting the Restricted Readers group, then clicking on the Settings item in the toolbar and selecting View Group Permissions.)

“Restricted Readers” is a prime example of a hazardous group, and “Style Resource Readers” (and their respective translations to all the different localizations) is another. They are used by SharePoint internally, so don’t mess with them! They are very, very much required in order for the Publishing infrastructure to work at all.

Of these 2 groups, Restricted Readers doesn’t have any visible members by default, but Style Resource Readers does. See the default members below.

The default permissions of "Style Resource Readers" -built-in SharePoint Group
The default permissions of “Style Resource Readers” -built-in SharePoint Group

Are those 2 groups intact and are members ok? Next thing to try!

How to create a subsite in Sharepoint

Time needed: 20 minutes

  • Style Library

    https://[siteurl]/Style Library/

    See the correct permissions below!

  • Web Part Catalog

    https://[siteurl]/_catalogs/wp

    Generally speaking, this list should inherit its permissions, so the first step might be to reset unique permissions if it has them.

  • TaxonomyHiddenList

    https://[siteurl]/Lists/TaxonomyHiddenList/AllItems.aspx

    Try giving ‘everyone‘ everyone read access and your timer service account ‘full control’ to the following list. I ran across this issue in the past and that resolved the issue.

    It might also be worth it to add “View Items” permissions level to “Anonymous Users” – that sounds hazardous, but that’s the default setting

  • UserInfoList

    This list is a pain to work with.
    You could at the very least check if you can access it.
    See further below for a code example.



    Below, you can see an example of how to access the UserInfoList. This example just lists the fields of the list, but you could also loop through the users (to verify that they are populating) or reset the list’s permissions if nothing else is helping.

    <pre lang ="csharp">var usersList = clientContext.Site.RootWeb.SiteUserInfoList;
    ctx.Load(usersList); // ctx is your client context
    // check that this list is not completely broken - list and access its fields
    foreach (SPField f in usersList.Fields)
    {
    System.Console.WriteLine("{0} - {1}",f.Title, f.InternalName);
    }</pre>

    Did that all help at all? No? Try the last resort solution in the final step

  • Dig into the ULS logs to find clues

    Okay, in that case, your next thing to try is going to be digging into the ULS logs. There’s a lot you have to go through, most likely, so better get started :) Look for any words like “unauthorized”, (or even just “authorized”, for “not authorized..), 401, “Access denied”, or even just “access”…

    • Good luck!

    References and sources

    These posts describe the reasoning behind some of these changes: 

    mm
    Latest posts by Antti K. Koskela (see all)
    0 0 votes
    Article Rating

    Posts Related to "Subsite creation in SharePoint fails with error 0x80070005 for any user (even global/farm admins!)":

    Subscribe
    Notify of
    guest

    0 Comments
    most voted
    newest oldest
    Inline Feedbacks
    View all comments