SharePoint cat fixing them errors

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

This issue seems to pop up bafflingly often, so I thought it’s 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 account 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

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 lead to this solution from this blog, that 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 diffecent localizations) is another. They are used by SharePoint internally, so don’t mess with them! Restricted Readers doesn’t have any visible members, 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 members ok? Next thing to try!

Ensure that the “Manage Hierarchy” permission level has the “Apply Themes and Borders” permission and the group Home members group (supposing that your members -group is supposed to have the permissions to create new subsites in the first place) has Manage Hierarchy permissions.

Fix the permissions of a couple of built-in lists

Fixing permissions of groups is one thing, but you might need to fix a couple of lists, too.

Add Read permission to Everyone for following lists:

  • DeviceChannels
  • MasterPage Gallery

Did that help? No?

No worries, we’re not out of things to try yet! See the lists below and their permissions gotchas:

  • Style Library
    • https://[siteurl]/Style Library/
    • See 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 permissioning ‘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.
    • Might also be worth it adding “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 on 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 lists permissions, if nothing else is helping.

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);
}

References and sources

These posts describe the reasoning behind some of these changes: 

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!