The user who's responsibility it is to build up and maintain our training portal is receiving the "Access Denied" message when she tries to edit her page. Her permission level is "Full Control".

I have tried removing/re-adding her. I have tried selecting multiple permission levels - both simultaneously and individually. Both with no luck.

Have just checked, the same happens for any user with full control permissions within this site.

Does anybody know what could be causing this?

Thanks in advance.

12 Answers 12



Though I'm still not certain why it occurred on this site and on no others...

I simply had to provide global read access to the master page library. Site actions > site settings > Master Page and page layouts > Library tab > Permissions. Add All authenticated users to READ ONLY.

  • 1
    Thank you very much. This really helped. I removed NTAuthority permission from the style resource Readers group to verify something but forgot to revert the changes.
    – user39984
    Feb 26, 2015 at 3:29
  • My problem solved when I give EDIT permission on Master Page and Layouts. But I just want to give READ ONLY permission. I gave it, but not working. Feb 26, 2015 at 4:34
  • 1
    Ok, I got the solution. I forgot to publish my custom master page. Feb 26, 2015 at 4:59
  • This works for SP2013 too. 2013 has the Style Resource Readers group in the Master Page Gallery > Settings in Permissions for this document library. Adding "Everyone" to this group which has Restricted Read access solved this issue where a user saw this message when trying to create a new wiki page in the Pages library.
    – Underverse
    Jan 19, 2018 at 2:32

The scope of your problem may range between the ones that are mentioned below. Have them carefully checked.

  1. Master page or the Page Layout used by the home page are being checked out by Site Collection Admin or is lying in "pending" approval state.

  2. Any custom solution that might be added in the landing page can cause access issues. Verify closely the uls logs for this.

  3. Incorrect configuration of Object cache reader account renders access denied to everyone including application pool identity account let alone your site collection admins and owners. See the Full read and Full read + write are correctly implemented incase object cache reader is configured.

  4. Permission level policy at the web application levels have changed or incorrectly modified. If this is the cause, verify that the issue persists in any other site collection within the same web application.

  5. The permissions of the homepage or the page the user is trying to edit of the site collection or the document library where the homepage resides has the correct permissions.

  6. Try to go through the ULS logs incase the issue occurs outside the scope of the above mentioned.

  • None of these directly solved it. However they led me to work out what the problem was, so thank you very much. Feb 28, 2013 at 10:57

if your site is a publishing site and you want people with read permission to see draft pages, you should make sure that these pages have been published at least once before.

  • Perfect! was what was happening on my site, thank you. Nov 18, 2015 at 12:29

Charles, the solution you applied should already have been in place, which means someone customised the permissions on the gallery.

The Style Resource Readers group was designed for specifically that purpose. Its default members should be NT AUTHORITY\authenticated users and/or Everyone.

When in doubt, check it all out. Compare the permissions to a newly-created Site Collection and you'll see what they should be.


Farm -> Application Management -> Site Collection -> Configure quotas and locks.

If it's in locked state, users and administrators can have permission denied while creating new list items, pages, or folders inside Sharepoint.


If you have created full custom page.So you have to give Page level permission on particular custom page.


Check whether the content DB is set to read-only mode. if it is in read only change it to “not locked” mode.


If you have disabled scripting from the SharePoint admin center

  1. Go to the SharePoint admin center
  2. Select Settings
  3. Under Custom Script choose:

Prevent users from running custom script on personal sites or Allow users to run custom script on personal sites.

Prevent users from running custom script on user created sites or Allow users to run custom script on self-service created sites.

With powershell immediately:

Set-SPOsite https://mysite/ -DenyAddAndCustomizePages 0 
  • Hi art! The question is tagged with 2010, so your answer for SPO is not really applicable. Although the settings above could very well have been the problem in an Online environment Oct 5, 2015 at 5:59

Check Drop off library, if users break inheritance and remove users from it, this is exactly what happens, it just happened to me today


I encountered this issue with a client today.

Firstly I noticed that the Master Page Gallery had unique permissions and secondly what finally resolved my issue was discovering that the site was using a custom master page, this master page had not yet been fully published.

Inheriting permissions and publishing a file resolved 4 hours of trouble shooting!


I had experienced this same situation. One user in an AD group with Full Control would get an "Access Denied" error when adding a "Link to a Document", but could perform all other full control tasks such as adding folders, setting permissions, etc. All others in the same AD group and with the same permissions could "Link to a Document".

TLDR: Master page was checked out; checking it in, re-publishing it, and approving it fixed the problem.

Troubleshooting: Comparing this user's access to others in the same AD group that was granted full access, the permissions were the same.

Looking at the permissions from the top of the site down, everything seemed to be in order. Checking permissions for the user, everything checked out okay (note: we follow grant not deny access methods so there was nothing denying access anywhere).

Following the advice in Arko D's post, I checked the Master Page and found it was checked out. I checked it back in, re-published, and approved it. This corrected the issue.

I'm still not sure why only one user experienced this issue, while all others in the same groups and with the same permissions had no trouble at all, but it may have something to do with when the page was checked out and the timing of when this user was added to the AD group or when the AD group was granted Full Control.


This solved my issue:

SharePoint O365 Permissions - Deny - Add and Customise Pages issue

In my case the permisions problem was in a team site under the main site, so I had to specify that as follows:

Set-SPOSite -Identity https://<yourdomain>.sharepoint.com/sites/<your team site> -DenyAddAndCustomizePages $false 

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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