8

I'm currently playing around with SharePoint 2010 but have come across an issue when using the standard Document Library and Announcement web parts. If I change the permissions to a list or library from inherited to custom permissions if a user doesn't have access to the list or library the web part displays the error shown below, instead of not displaying the web part to the user.

Web Part Error: Access denied. You do not have permission to perform this action or access this resource.

The thing thats confusing me is that the error only shows if the web part is within a web part pane, if I add the web part to a rich content area and a user doesn't have permissions to see a list it simply doesn't display.

If anyone knows how this can be resolved, please let me know. It looks like the issue dates back to SharePoint 2007 from what I've seen and have seen a technet article (919550) for SharePoint 2007, but does not yet say it applies to 2010 and have tried the workarounds contained within such as setting the target audience of the web part, but this has had no affect.

update I've since forwarded this issue to Microsoft who have been able to replicate the fault and are currently working on a resolution.

3
  • Is it possible to put a rich content area within a web part zone and then insert the data view into that rich content zone?
    – James Love
    Aug 2, 2010 at 16:38
  • Is there a solution to this issue? Coming up against it myself a year and a half later... When trying to add a web part directly to Rich Content rather than a webpart zone, the page looks like it's saving/adding the webpart but once the browser refreshes, there's nothing in the RCE.
    – Beeblebrox
    Feb 7, 2012 at 0:00
  • The final solution worked for me (Yes, we're still using 2010). You can then apply Audience Targeting and then hide the Webpart completely as having an empty library gives a false positive. You can always add some narrative to the page to explain this to the User who don't have the correct permissions. May 6, 2020 at 9:04

6 Answers 6

4

Yes there is a solution to restricted document libraries showing up with 'Web Part Error: Access Denied'.

On the restricted document librarly, you can give the build-in Windows Domain Group 'NT AUTHORITY\authenticated users' Site Permissions for 'Open' (Allows users to open a Web site, list, or folder in order to access items inside that container.)

This is a custom permission level that you need to create (you only select 'Site Permissions: Open' permission. Then you assign this permission to 'NT AUTHORITY\authenticated users' - which would apply to any logged in user. Then the user can open the document library without being able to read any items within it.

The error on the web part is due to the user not having enough permission to even open the document library. You can allow the user to open the document library, but not read any content. Then all works well, we use this all the time on both SharePoint 2007 and 2010, and don't get the annoying error on the web page.

1
  • I am using SharePoint 2013. The option you described is not available. I used this option instead: "Restricted Interfaces for Translation - Can open lists and folders, and use remote interfaces." Now list view web parts show "There are no documents in this view" to unauthorized users, and clicking on the list title (a link to the list) results in an Access required page popping up.
    – user22303
    Oct 9, 2015 at 13:29
2

I have dozens of dashboard pages that include List View web parts with custom permissions. They all display as expected.

The reason you see this error is because of poorly implemented permissions on lists and libraries. When breaking inheritance at this level you should ensure that default reader groups have the Limited Access permission level applied.

You do not have to take B Bennin's approach. Simply hit each affected list or library and add the Restricted Readers group back with Limited Access. You may even want to try Restricted Read and compare results.

If you also add Audiences to the web part settings this provides the option to completely hide the web part from view, which is often much more pleasant than any empty list view.

1

We are seeing this exact same thing while we attempt to upgrade from 2007 to 2010. What is worse, as manemawanna stated, if the user doesn't have rights to the document library, even the Audiences on the web part are ignored and the the web part shows the error.. We use document level security extensively on our sites, and this problem breaks almost all of our document libraries! This will prevent us from upgrading to 2010. I see CU1 is out now, but nothing mentioned there seems to address this issue.

Manemawanna, have you heard anything new from MS on this issue??

Thanks!

Paul

1
  • Hello Paul, just so you know we have CU1 applied to both our dev and live servers and it does not resolve the issue. Microsoft have been in touch and are refunding/closing the call as to put it simply they said it's how SharePoint should work after getting in touch with some of the specific support and development teams. I am waiting for further responses though regarding the audiences, but as of now I would just leave it for the moment if you upgrading as there is no fix. We are in a different situation where this is our first SharePoint deployment and at the stage where we need to push on.
    – Anonymous
    Aug 25, 2010 at 10:27
1

Turns out the functionality I described at the start of the thread is how SharePoint is supposed to work.

1

But how can this be by design!!!?? The scenario of, having a user acess a site, that in it's homepage has a list view, of a list that doesn't inherit permissions, and the user doesn't have permissons on any item, seems quite a normal scenario, don't you think?

1

I know the answer to this problem. Have been researching it for more than a week, thoroughly frustrated with the lack of documentation I've found. My problem was it was showing up in the Production environment but not in my QA environment so I did NOT want a workaround to just NOT DISPLAY the Web Part Error: Access Denied as it did not get to the root cause which is this:

I have a number of sites with libraries that have been disinherited from the parent site's permissions. Each site has specific libraries that are not shared with everyone the same as the parent site level.

Style Resource Readers was correctly granting Read and Restricted Read (for Style Library and Master Pages, etc.) as expected at the top level of the Site Collection. However, at the subsite level, SRR group was not providing the Limited Access when creating new sites as would be expected.

The Style Resource Readers permission group was not granting the "Limited Access" needed to render the document library web parts as expected. What I wanted (the way it was correctly displaying in QA) was this: I want my front page to show the library web parts with library title but not show any document or content not shared with specific users. If they don't have permissions in the library, they should not see any error message displayed like this: Web Part Error: You do not have permission to perform this access or access this resource. Correlation Id: xxxxxxx

The steps I had to take to correct in the Production environment: Take the site down for maintenance for a couple hours. Reinherit permissions on each site from the top level parent so Style Resource Readers (SRR) group would correctly cascade down (it did NOT work to just add this SRR group in at the Site Level with Read permissions) Reinherit all additional subsites and libraries. Then go back to each of the sites and subsites and break inheritance in each; remove all the groups that came down from the parent. Then finally go back to each of the individually-permissioned libraries and apply the explicit permissions to only those people and groups that should see the contents of any given library.

Voila! No Web Part Errors anymore!!

Your Answer

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