sufficient Application pool account privileges

Question

Had an exception while creating a sub site (copy pasted lines from logs below).
figured from logs that it's a permission related exception since error code: 0x80070005
and that it happens while creating a list instance of Shared Documents doc library, probably while creating some taxonomy column.

This can be solved by adding application pool account to the farm administrators, but it's recommended not to.

So which permissions should I assign to app pool acc to get this thing working?
-----
Unknown SPRequest error occurred. More information: 0x80070005

<nativehr>0x80070005</nativehr><nativestack></nativestack>
<nativehr>0x80070005</nativehr><nativestack></nativestack>

Leaving Monitored Scope (List Creation: Shared Documents). Execution Time=623,7974
The element of type 'ListInstance' for feature 'SharePoint_Web.CollaborationSiteContent' (id: 07eba46b-1799-4299-9411-36a68eb3f1cd) threw an exception during activation: Exception has been thrown by the target of an invocation.
Feature Activation: Threw an exception, attempting to roll back.  Feature 'SharePoint_Web.CollaborationSiteContent' (ID: '07eba46b-1799-4299-9411-36a68eb3f1cd').  
Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.UnauthorizedAccessException: <nativehr>0x80070005</nativehr><nativestack></nativestack>     
at Microsoft.SharePoint.Library.SPRequest.OpenWebInternal(String bstrUrl, Guid& pguidID, String& pbstrRequestAccessEmail, UInt32& pwebVersion, String& pbstrServerRelativeUrl, UInt32& pnLanguage, UInt32& pnLocale, String& pbstrDefaultTheme, String& pbstrDefaultThemeCSSUrl, String& pbstrThemedCssFolderUrl, String& pbstrAlternateCSSUrl, String& pbstrCustomizedCssFileList, String& pbstrCustomJSUrl, String& pbstrAlternateHeaderUrl, String& pbstrMasterUrl, String& pbstrCustomMasterUrl, String& pbstrSiteLogoUrl, String& pbstrSiteLogoDescription, Object& pvarUser, Boolean& pvarIsAuditor, Int32& plSiteFlags, Boolean& pbOverwriteMUICultures, Boolean& pbMUIEnabled, String& pbstrAlternateMUICultures, Int32& puiVersion, Int16& pnClientTag)     
at Microsoft.SharePoint.SPWeb.InitWebPublic()     
at Microsoft.SharePoint.SPWeb.get_LanguageCulture()     
at Microsoft.SharePoint.SPWeb.get_Title()     
at Microsoft.SharePoint.SPSite.OpenWeb(Guid gWebId, Int32 mondoHint)     
at Microsoft.SharePoint.SPFieldLookup.set_LookupWebId(Guid value)     
at Microsoft.SharePoint.Taxonomy.TaxonomyField.<>c__DisplayClassa.<Initialize>b__8()     
at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()    
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.Taxonomy.TaxonomyField.Initialize(SPFieldCollection fields)     
at Microsoft.SharePoint.Taxonomy.TaxonomyField..ctor(SPFieldCollection fields, String fieldName)     
--- End of inner exception stack trace ---     
at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionListInstances(SPFeaturePropertyCollection props, SPSite site, SPWeb web, Boolean fForce)     
at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionElements(SPFeature PropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, Boolean fForce)     
at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, Boolean fForce)

Answer 1

In CA -> Manage Service Applications, highlight your Managed Metadata SA and click on Permissions.  Try adding your Application Pool account here with the appropriate rights and see if that resolves it.

---

http://sharepoint.nauplius.net

Answer 2

Application pool account was already listed there with all permission checked, also it was listed in SA administrators.
So it didn't do the trick.

Has there been any bug fixes raleted to this one lately?
Just noticed that last CU that has been installed is June 2011 with SP1 + some individual hot fixes

Answer 3

As stated in this article that permissions for the application pool accounts are autoconfigured as follows:

Application pool account

The application pool account is used for application pool identity. The application pool account requires the following permission configuration settings:

The following machine-level permission is configured automatically: The application pool account is a member of WSS_WPG.

The following SQL Server and database permissions for this account are configured automatically:

• The application pool accounts for Web applications are assigned to the db_owner role for the content databases.
• This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the farm configuration database.
• This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the SharePoint_Admin content database.

it seems that not all permissions are correctly configured if you have changed application pool account afterwards. http://blog.sharepointrx.com/2010/12/01/updating-the-application-pool-account-on-a-sharepoint-2010-site/. I have no idea if this is the case, but I will have to check these permissions when I gain access to the DB.

Answer 4

There privileges were as stated in technet article in DB. Account was assigned to the WSS_CONTENT_APPLICATION_POOLS.
Furthermore account has db_owner role in Managed metadata db.

I've tested this further and this only happens if you apply a templeta which has Managed metadata field defined in it's document libraries. Otherwise there is no problems occur.
So what kind of privileges will Application pool account get when added to the farm admins that could affect provisioning of managed metadata fields?

Answer 5

Though I'm able to create a sub site (which does not have problematic Shared Documents doc library template)and I can successfully create document library from doc lib template which has exact same columns defined. That works fine in a separate process, but not when provisioning whole site.
Just can't get my head around to it.

Answer 6

Hey Mate,

We had a similar issue - we were running elevated for a site in one web app to access list data from a site in another web app with different app pool identity.  I found the code fails once it gets down to the Microsoft.SharePoint.Library.SPRequest level - it appears to get its knickers in a knot over permissions...

There were a couple of ways to get around this:

1) Set the application pool identity to be the same for both web applications

2) Use impersonation to impersonate the application pool account rather than using runelevated.  The difference between these two approaches is that impersonation doesnt create a separate thread whereas running elevated does, and I think the SPContext gets mucked up on this separate thread which ends up causing the unauthrorizedaccessexception at the Microsoft.SharePoint.Library.SPRequest level (COM) level.

If you found any other way around this I would be interested.

Regards,

Peter