Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Strange permissions problem

  Asked By: Zoe    Date: Aug 05    Category: Sharepoint    Views: 3428

A list and a library with unique permissions (no inheritance from the parent
site) somehow removed a user from those permissions when I removed the user from
the *site* permissions. Why would that happen? Since it doesn't inherit,
wouldn't it ignore any permissions changes I make to the site itself? The user
account still exists for that site collection.

Background Info: We have a site w/ several subsites. Most sites are workspaces
that do not inherit permissions from the parent. We also have at least one list
and one library that don't inherit permissions. We have a site admin that was
added as an individual with full control a long time ago, and she is now about
to retire.

Two days ago, I added her to a new "owners" group, along w/ the person who will
be taking over the site management. AFTER I created the group, granted the full
control permission level to it, and added her to that group, I deleted her
indivdiual permissions from each site. I didn't remember to go in and change the
list and library w/ unique permissions (mainly because I didn't remember that
they HAD unique permissions), so I would assume those would have stayed the same
(she would still have full control, but the new person would not have any
permissions since I had not added that new "owners" group).

She then told me that both the list and library would not let her add any
content. I went in and saw that her name had been completely removed from
permissions for the list and the library.

Any ideas? And if it helps- the group for the entire team (which includes the
site admin) generally has contributor rights for all sites. The reason for
unique permissions for the list and library are to make sure they cannot edit
content in those areas. It is only to be used by the site admin. And the
workspaces w/ unqiue permissions are so that they could add some additional
people as readers for just those workspaces.

Anyway, sorry if this is too much detail. I just don't know what's causing this,
so I don't know what is and isn't relevant.



13 Answers Found

Answer #1    Answered By: Lakeshia Gould     Answered On: Aug 05

Yes, we've noticed this behavior also. This is just SharePoint functionality.
Maybe the next version will have that little issue solved.

Answer #2    Answered By: Lizbeth Macdonald     Answered On: Aug 05

If you are using the same group  that would cause what you are seeing. While the
site may not beinheriting permissions, the group is the same. Adding or removing
users from the group will give them access where ever that group is used. To
avoid this, you need to create unique  groups when you break inheritance.

Answer #3    Answered By: Cole Curtis     Answered On: Aug 05

Or to clarify even further - groups are stored at the site  collection
level, not the web/subweb. Changes to a group  in any site affect the
entire site collection, this has nothing to do with whether inheritance
is broken or not.

Answer #4    Answered By: Debbie Snow     Answered On: Aug 05

To expand on this. permission  Level definitions are stored at the site
collection level  also. The only thing stored at the level of the site  or other
securable object is the connection between user/group, the securable object, and
the permission level.

Answer #5    Answered By: Adalberto Merrill     Answered On: Aug 05

I guess what is confusing to me is that her account in the
site collection  was not deleted. And the group  I added  her to was an entirely
new group (she wasn't removed  from any SP groups). She was originally listed as
an individual  with "full control" permissions. I created  a new SP group, added
her to it, added "full control" permissions  to that group for that particular
site, and THEN deleted  her individual permissions from the site. And somehow
that triggered the two lists w/in that site  that had broken permission
inheritance to remove her permissions altogether. The new SP group was not added
to those lists, but her individual permissions were removed. It's as if it is
"somewhat" inheriting permissions from the site. To me that is unexpected

Does that make sense? It sounds like Laura has experienced the same problem.
Very strange, and something I need to keep in mind since we do occasionally add
individuals directly to site permissions (although I know it is not a best

Answer #6    Answered By: Lynsey Carver     Answered On: Aug 05

Actually, I would expect that to happen. Because the lists were configured as
not inheriting, adding a new group  to the site  would not be noticed by the
lists, so she would not be given any access to those lists. Also, since here
account was added  at the site, and I will likely guess it was added there before
the lists broke inheritance, when you remove the account from the site, all
references to that object are removed  as well.

Answer #7    Answered By: Richard Allen     Answered On: Aug 05

Is there a difference if the site  containing the list  is a top-level site as
opposed to a subsite?

This is an area of potential confusion because the "People and Groups" page
under "Site Settings" is really about the site collection, even if you
access it from a subsite.

Answer #8    Answered By: Ian Davis     Answered On: Aug 05

Not really. permissions  are really a site  Collection issue. When you break
inheritance at a sub site, if you really want maintain unique  permissions for
that sub site you need to create new groups for the site and populate those.

Answer #9    Answered By: Jagjit Hui     Answered On: Aug 05

This is all making it more clear to me how important it is to use
SP groups for just about everything.

I am curious about your last sentence, though. I am understanding that, while
lists and subsites  may not be "inheriting" permissions  for the parent, they are
in some way inheriting the individual  people from the parent site  (or something
like that?). Your last sentence, though, says to "remove the permissions at the
site level  without deleting the user  from the AllPeople list." I did that-
removed the person  from the site permissions, and I did not go into the site
collection users (a.k.a. All People) to delete her. Her account still exists  on
the All People page.

My plan is to use groups whenever possible (even for lists w/ broken
inheritance) and to make careful note of where permission  is NOT inherited so I
can double-check everything.

Answer #10    Answered By: Alexia Mccarty     Answered On: Aug 05

Let me try to clarify. What is normally recorded at the site  or
list/Library level  with custom permissions  is the connection between a
user/group and a permission  level for that securable object. But the actual
person, group, or permission level is normally created  and stored in the top
level site of the site collection. When you break inheritance  on a
list/library it copies the connection between the users/groups and
permission levels. It doesn't copy the actual users/groups or permission
levels. So if you go back to the root site and delete the user  then it will
delete the connection in the list  or library  below since its no longer

Answer #11    Answered By: Laquita Mcgowan     Answered On: Aug 05

You will discover that the same thing happens when using groups.

For people who have never tried this, here are some steps:
1. create a new subsite for testing and use the default selections
2. then break the inheritence on the first subsite from the parent site  and make
yourself an owner (if not already), and remove all other permissions.
4. break the inheritence of a document library  or list  in this site
5. grant both an individual  and a SharePoint group  contribute permissions  on the
library/list, and you should remain an owner of it.
6. View the site permissions on the test subsite you created. Site permissions
are on this page /_layouts/user.aspx

You will see that the person  and group that you assigned contribute permissions
both appear in the site permission's list, but with "limited access"

7. Remove both the person and the group from the subsite's site permissions.
Their permissions will also be removed  from the document library or list.

The danger I found with this unexpected behavior, is that it is easy to forget
why someone shows up with "limited access", and I was cleaning up apparantly
stray individuals from a site's permissions list one time. These same people
already had access to the site as members of a SharePoint group, so I initially
saw no value in their individual "limited access" permission  on the site, and I
ignored the warning that SharePoint provides: "You are about to remove all
permissions..". The result is that I removed their access to private document
libraries that had been set up for their use within the site.

Answer #12    Answered By: Elijah Davis     Answered On: Aug 05

Any Sharepoint Administrators looking for a position?

Answer #13    Answered By: Akanksha Jain     Answered On: Aug 05

This is starting to make more sense. It actually may explain quite a
bit. This is really good to point out so folks don't haphazardly removed  the
"limited access" permission.

Didn't find what you were looking for? Find more on Strange permissions problem Or get search suggestion and latest updates.