Lately, we had a customer whose SharePoint environment suffered from an unknown access denied error, when a user with full control cannot create subsites in the site collection. Each time these users tried to create either a project or team site they got “Sorry, you don’t have access to this page” or “Access Denied”.
This blog outlines how you could resolve this issue, often caused by permissions within the SharePoint Taxonomy Hidden List.
Symptoms – User cannot create subsites
- Each time these users tried to create either a project or team site they got “Sorry, you don’t have access to this page” or “Access Denied”.
- It appeared SharePoint was ignoring the full control access permission (Owners Group).
- A user with Site Collection Administrator permissions could create subsites.
- New Site Collections on the same web application normally operated without this issue.
Investigation
- We started by activating verbose ULS (Unified Logging System) on the SharePoint server.
- Users then attempted to create subsites, and we pulled the logs for this time.
- We first noticed “Access is Denied” error messages within the ULS logs.
- A number of lines above this “Access is Denied” event it stated that an UpdateField request was being performed on a list identified at that time as c442bc26-f509-4ec7-9da0-a8fe0234924e. Here is that event.
SPRequest.UpdateField: UserPrincipalName=i:0).w|s-1-5-21–4218016322-16051, AppPrincipalName= ,bstrUrl=https://server/sites/name/team ,bstrListName={E8F681E0-C8AB-4454-9C52-376AADCB7112} ,bstrXML=<Field Type=”TaxonomyFieldTypeMulti” DisplayName=”HashTags” StaticName=”HashTags” Name=”HashTags” ID=”{333b1bc2-0532-4872-96f1-bbbdead35a56}” Description=”Some description” SourceID=”{2e9ba01e-b042-49ce-8993-e16635268252}” List=”{c442bc26-f509-4ec7-9da0-a8fe0234924e}” WebId=”18b250fa-8e7f-4410-806d-
- We then ran the following command to find the list friendly name and its location within the troubled the site collection.
Get-SPSite https://server/sites/team | Get-SPWeb -Limit ALL | %{$_.Lists} | ?{$_.ID –eq “c442bc26-f509-4ec7-9da0-a8fe0234924e”} | ft Title, ParentWebURL, RootFolder
- The list in question was the SharePoint Taxonomy Hidden List which acts as a storage area for specific term store information for the SharePoint managed metadata service.
- The list can be reached through the UI using the following URL [site]/lists/taxonomyhiddenlist
Root Cause – Taxonomy Hidden List
- This Taxonomy Hidden List list was not inheriting security and was found to be stripped bare of any user or group listings.
- Administrators may have stripped these hidden lists using a PowerShell command during a process to clean up permissions on the site collection in staging, preparing it for migration to their production server.
- [26 November 2014] This may have also been due to migration from one server to another, but the server where the site was backed up, may not have been using the SharePoint Managed Metadata service. Therefore once the site was restored the SharePoint Taxonomy Hidden List was not given the read access.
Resolution
- The solution was simple once identified, give the SharePoint Taxonomy Hidden List read access for all Authenticated Users operating within the Site Collection.
This issue was a difficult one to identify; I hope this helps you overcome the problem more efficiently where the user cannot create subsites.
Jonathan
[Orginally posted 31 Oct 2014]