Access Denied Errors Activating Publishing Features in a SharePoint Team Site

Many organizations have a governance policy in which certain individuals are granted Full Control permissions of individual sites, usually after completing some training or demonstrating proficiency in site administration skills. In such a scenario, it is quite common for a number of different users to be site owners throughout a wide or deep site hierarchy without having any permissions beyond the sites the administer or to the parent site collection(s); in fact, they may not be any more than a common Visitor in the root site collection even though they are in the Owners group of their own site(s).

While this is an effective strategy for delegating site administration and support duties to non-IT personnel it can sometimes lead to unexpected permissions issues. Case in point: activating the SharePoint Server Publishing feature on a site. This feature, which provisions the various artifacts required for publishing and enables various publishing-related settings, is dependent upon a site collection scoped feature called "SharePoint Server Publishing Infrastructure".  Site owners without administrative site collection permissions must first request activation of the dependent feature by the site collection owner before attempting to activate the publishing feature on their own site. In theory, this should be sufficient but unfortunately, activiation of the dependent feature is not enough to enable publishing on a child site – the site owner must also have a minimum set of permissions on at the site collection level.  

If you have ever encountered this situation, then you have likely recieved the standard "Sorry, you don’t have access to this page" screen when attempting to activate the publishing feature. This error can be misleading, as attempting to activate a feature doesn’t have anything to do with trying to navigate to a page, but the underlying cause is the same – a System.UnauthorizedAccessException error is being thrown and the custom errors mode parser always redirects to the /_layouts/15/AccessDenied.aspx page if the "Allow access requests" option is checked under Access Requests Settings. The ULS log entry for this would look something like the following:

Event log message was: ‘Failed to initialize some site properties for Web

 at Url: ‘http://portal/sites/test/newsite”. Exception was: ‘System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))    

 at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex)    

 at Microsoft.SharePoint.Library.SPRequest.SetWebMetainfo(String bstrUrl, Object varMetainfo)    

 at Microsoft.SharePoint.SPWeb.Update()    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.SaveNoMobileMappingsInfoToRootWeb(SPSite site, SPWeb currentWeb, Boolean mappingsFileExists, Boolean hasNoMobileMappings)    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.<>c__DisplayClassc.<UpdateFile>b__a(SPSite elevatedSite)    

 at Microsoft.SharePoint.Publishing.CommonUtilities.<>c__DisplayClass1.<RunWithElevatedSite>b__0()    

 at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass5.<RunWithElevatedPrivileges>b__3()    

 at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)    

 at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)    

 at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.UpdateFile(Dictionary`2 mappingsToBeSaved)    

 at Microsoft.SharePoint.Publishing.Mobile.MappingsFile`1.Update(Dictionary`2 mappingsToBeUpdated, Boolean forceOverwrite)    

 at Microsoft.SharePoint.Publishing.CustomMasterUrlProperty.SetDirectChannelSpecificValue(SPWeb web)    

 at Microsoft.SharePoint.Publishing.CustomMasterUrlProperty.SetDirectValue(String value, SPWeb web)    

 at Microsoft.SharePoint.Publishing.InheritableProperty`1.SetInherit(Boolean inherit, Boolean forceAllSubWebInherit, String successUrl, String failureUrl, Boolean& updateRequired)    

 at Microsoft.SharePoint.Publishing.InheritableProperty`1.SetInherit(Boolean inherit, Boolean forceAllSubWebInherit, Boolean& updateRequired)    

 at Microsoft.SharePoint.Publishing.Internal.AreaProvisioner.SetMasterPageProperties(PublishingWeb area, Boolean& updateRequired)    

 at Microsoft.SharePoint.Publishing.Internal.AreaProvisioner.SetLayoutRelatedProperties(PublishingWeb area, Boolean& updateRequired)  

There are numerous posts on the Internet which indicate that the solution to this problem is to give the user attempting to activate the feature at least "Read" permissions to the "DeviceChannels" list in the parent site collection. This is due to the fact that DeviceChannels, along with several of the other publishing-related lists such as "PublishedLinks" and "ReusableContent", have permission inheritance broken when they are created and the user in question won’t have the ability to even read these lists. While activiation of the site-level publishing feature does, in fact, read from the DeviceChannels list, applying permissions only to this list may be insufficient. Testing on 2010 RTM/SP1/SP2 and 2013 RTM has shown that the site owner must also have "Member" rights plus the following site permissions on the root site collection in order to activate the publishing feature:

• Add and Customize Pages – Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Microsoft SharePoint Foundation-compatible editor. 
• Apply Themes and Borders – Apply a theme or borders to the entire Web site. 
• Apply Style Sheets – Apply a style sheet (.CSS file) to the Web site. 

Esssentially, this is the same permission set as the "Designer" role with a few exceptions, such as "Use Self-Service Site Creation", "Browse User Information", etc.  If assigning site owners full Design permissions is considered too permissive for your environment, you can create a custom permission level and group, then assign site owners to that group. Unfortunately, this means the site owners will also have rights to modify styles, master pages, and so on at the site collection root, which will probably not comply with the governance policy in most organizations. Other alternatives are to handle feature activiation via a PowerShell script or custom code. Alternatively, the site collection administrator could create a site template that already has the SharePoint Server Publishing feature activated and use that template for the creation of subsites as the design permissions are only required when activating the feature not for using the publishing components after it has been activated. Temporary assignment of these permission is also a potential workaround but it requires active participation by the site collection administrator. If you are using an advanced workflow solution like Nintex or K2 you might also be able to automate the process using an app step or elevated permissions within a workflow.