Lesson Learned: Removing “Limited Access” permissions overrides item-level security settings in SharePoint

securityHere is one to chalk up to the “I-should-have-known-better” category.  The other day I needed to make some permissions changes to a SharePoint list, and the items within this list had special permissions (item-level security).  After making the necessary changes at the list level, I noticed that there were a lot of individual people in the list permissions with “Limited Access.”  Since I don’t like clutter, I thought I would just clean things up by removing the users that had Limited Access.

That was a mistake!  Removing the users with Limited Access from the list’s root level permissions settings also removed all those users from the items in which they had item-level security set up!

Thinking about it after the fact, this makes perfect sense.  By definition, Limited Access allows users to access certain areas of the site, such as a specific list, library, item, or document, without giving users access to your entire site.  So removing a user with Limited Access will in fact remove that user from all the areas in which they had fine-grained permissions set up.

I was very lucky because for this particular list I had a PowerShell script written that sets the item-level security based on a person’s department and manager that can be run on demand (usually I run it whenever we have issues with the list or need to add a permissions exception).  Simply running this script added back in all my item-level security permissions, but it could have been a nightmare if that script didn’t exist!

The moral of the story is to be very careful before removing any kind of permissions, and make sure you have a thorough understanding of what exactly it is that you are removing.  And having your user permissions documented would be very beneficial in case you do accidentally delete someone’s permissions and need to restore them.

(Visited 18,030 time, 1 visit today)


Click here to post a comment

  • The same exact thing to me too. I was trying to clean up and remove the users with limited permissions at the site. Next thing you know, I had users reporting problems that they lost permissions

  • Yes it needs to be more clear, or at least not so easy to delete those permissions. I’m sure we’re not the only ones that this has happened to.

  • The issue comes from the naming (“Limited Access”) of the permissions shown at the list level for some custom permissions at item level
    (same applies in case of permissions at site level, if you have custom permissions on a given list)

    The permissions for the file system (NTFS) has an equivalent permission named “Traverse folder” (Traverse Folder: Allows or denies moving through a restricted folder to reach files and folders beneath the restricted folder in the folder hierarchy.)

    It would make a real difference reading a permission set like this: “Traverse list – item level security set-up” (or “Traverse site – list level security set-up”)

  • Equally dangerous is resetting permission levels to inherit. For some reasond behavior is to reset permissions to inherit as well. A warning of this behavior would have been nice.

  • Hi Wendy,

    Interesting post. I am currently having this issue in an O365 environment where I removed limited access users and they now cant access certain sites.

    How do I restore this ? and advice would be appreciated.

  • but the question is instead of removing the ‘limited permission’ users, why cant we have feature to hide those permission at root folder for limited access. There should be an option either you want to view all permissions (including ‘limited access’ users) or only non- limited access permission users.

About Me

Wendy Neal

Wendy Neal

I am a .NET SharePoint Developer for DMI. I've worked with SharePoint since 2007. I love to share my passion for SharePoint and Office 365 by speaking at various industry and user group events, as well as writing articles for various publications and this blog.   Read More

MCSA Office 365
Top 50 SharePoint Blogs

Buy My Book


  • 2018 (1)
  • 2017 (1)
  • 2016 (8)
  • 2015 (23)
  • 2014 (20)
  • 2013 (22)
  • 2012 (15)
  • 2011 (13)