Problem: One day, seemingly out of the blue, I received an email from a coworker that they couldn’t edit a SharePoint page (it was on a publishing web) that they had previously created, edited, and published. It sounded like a weird issue, so I went to the page myself, edited and published it, and everything was A-OK. I initially assumed my coworker was just going a little crazy, and let them know it was working for me. So I walked over and watched what they were doing, and everything seemed normal in their process. The problem was that they continued to get an ‘Access Denied’ message whenever they edited the page. For the laundry list of symptoms/discoveries, see the next section.
- Access Denied message when attempting to edit a page
- Access Denied message after creating a page
- Nothing in Application/Security Event Logs
- Nothing of note (aside from an indication of access denied) in the default ULS log parameters
- Site Collection Administrators were not impacted (they could edit pages just fine)
- All other non-Site-Collection-Admins were impacted (they couldn’t edit pages at all)
- Feature-cycling the Publishing Infrastructure and Publishing features didn’t help at all
Solution (for the impatient):
The most annoying problems seem to always have some of the easiest solutions…In this case, (somehow) the NT Authority\All Authenticated Users group had been removed from the Style Resource Readers SharePoint group. Because of this, editors couldn’t interactively load the publishing page layouts as is required when putting a page in edit mode. All it took was re-adding this group to Style Resource Readers and everything was back to normal. Problem Solved! (See below for how we got there)
The road to the solution:
After testing through(read: discovering) all of the above-mentioned-symptoms, I was nearing the wits end of my troubleshooting-rope. However, a coworker then reminded me that I could turn-up my logging in SharePoint to see if it would give me some more useful events in the ULS logs. So I turned up the following 5 groups to the highest level (Verbose).
- SharePoint Foundation –> Logging Correlation Data
- SharePoint Foundation –> Monitoring
- SharePoint Foundation –> SQM
- SharePoint Foundation –> General
- SharePoint Foundation –> Database
This was likely overkill, but I wanted to figure out where SharePoint was blowing up…Luckily, the choice to turn logging into a 200lb gorilla panned out. If you look at the screenshot below, you’ll see that I’m looking at the event (right-side) just after the access-denied message. This event details the user didn’t have access to the Page Layouts library (which is, of course, the Master Page and Page Layout gallery at the site collection level. After a quick trip with a non-SCA user, it was discovered that I could read that library at all. As detailed in the Solution section, all that needed to be done was adding the appropriate group to the Style Resource Readers SharePoint group and the problem was fully resolved. After validating the resolution, I reset my logging to normal, and continued on with my Friday. :-)
Tools Used (aside from SharePoint 2010 and Windows Event Viewer):
ULS Viewer – If you’ve never used this, I highly recommend it. It’s actually an archived Microsoft project, but it does a famous job of reading ULS in real-time, replete with filtering/grouping/etc. Since I had crazy-levels of logging turned on, I started the logging, quickly hit the access denied page, and then turned logging off. By doing this, I minimized the number of garbage entries that I’d have to dig through.