Forum Discussion

Deleted's avatar
Deleted
Mar 03, 2017

Breaking Inheritance on a Document Library in an Office 365 Group Site

Interesting situation. I have a requirement to add an additional library to the Site of an Office 365 Group and break the inheritance and remove groups etc. It seems that when you try to break inheritance in an Office 365 Group Site the options are not available (greyed out)? I can break inheritance OK but cannot remove groups. Can add them OK but not remove.

 

Anyone else experience this?

  • We have been discussing this in many threads in the Groups space...Microsoft is "simpliflying" and "changing" how security is managed in Group sites compared with what we are used to do in classic sites...basically what you are trying to do seems to be an scenario that at this stage is not fitting very well with the security model they have designed for Groups
  • This is where understanding the requirement before the site/group is created will be critical. I suppose this might be because of other Apps (such as Planner, Team, Outlook, etc.) involved.  I think the approach Microsoft has taken is, member of a group is a full member and you give have restricited access, it is full or nothing.

    • Salvatore Biscari's avatar
      Salvatore Biscari
      Silver Contributor

      It looks like you can again edit/remove default permissions after breaking inheritance.

      In fact, after breaking inheritance, I have successfully removed the Members group and changed the permissions of the Visitor group in the main doclib of a private Group.

      jcgonzalezmartin can you confirm it?

      • Sohail Merchant's avatar
        Sohail Merchant
        Brass Contributor

        Update:  I stand corrected, you can actually break the permission of a document library and give access to certain people.  People with unique permission won't show up under group membership on the top as member / visitor 

         

  • Yes, as Juan said, at this stage this behavior is "by design".

    It appears that Microsoft consider not logically coherent to have SPO resources in a Group that are not accessible to Group members.

    Hence you should use a different Group or go with a classic team site.

  • We have been discussing this in many threads in the Groups space...Microsoft is "simpliflying" and "changing" how security is managed in Group sites compared with what we are used to do in classic sites...basically what you are trying to do seems to be an scenario that at this stage is not fitting very well with the security model they have designed for Groups

Resources