SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having trouble changing the site theme in my SharePoint Foundation 2010 environment.

When I do Site Actions > Site Settings > Look and Feel > Site Theme, i receive:

Error: Access Denied

I currently have Full Control over the site.

When verifying the User Permissions in Central Administration, I can see that All Permissions are enabled (including "Apply themes and borders").

I can find nothing in my ULS logs concerning this.

There is not a single site where I can change the Site Theme.

Please advise.

After fiddling with the permissions I managed to reach the theme selection page on 1 subsite. But after selecting any theme for that site I receive the error:

Error Attempted to perform an unauthorized operation. Correlation ID: x

When I filter for the Correlation ID I see 3 messages:

  • Name=Request (POST:http://URL/Site/TestSite1/_layouts/themeweb.aspx)
  • Site=/
  • Leaving Monitored Scope (Request (POST:http://URL/Site/TestSite1/_layouts/themeweb.aspx)). Execution Time=43.8902150971702

These messages aren't very useful.

All the other sites still give me the Acces Denied error.

share|improve this question
Have you tried an IIS Reset or an AppPool recycle? – Daniel Ziga Nov 12 '12 at 12:49
@Dandroid - I've done an IIS reset and AppPool recycle, to no avail. – TempaC Nov 12 '12 at 12:57

Try setting yourself as Site Collection administrator and retry.

share|improve this answer
I've added myself as Site Collection Administrator. I'm still unable to change the Site Theme. I've performed an IIS reset aswell. No joy. – TempaC Nov 12 '12 at 12:33
Same happens on site collection ROOT site as well? – Jussi Palo Nov 12 '12 at 12:38
The same error occurs on the site collection root as well. – TempaC Nov 12 '12 at 12:42
up vote 0 down vote accepted

The solution to this problem was performing a Site Collection backup and restore to a new web application in a new content database. It turned out that the old Content Database belonged to the devil.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.