SharePoint Online permissions inheritance is killing me; Google is failing me

I have a small site, pre-configured with two SharePoint groups for external users, and two document libraries. Because reasons, the site's not connected to Teams.

When I stop inheriting permissions in a doc library, the popup says (paraphrasing), "SP copies permissions from the parent and stops inheriting. Changes to the parent permissions made in the future won't apply."

BUT...

Back in *site* permissions (the former parent), if I add users in a SharePoint group, they're added in the group in the document library to which I just broke permissions inheritance.

And if I add users in the group in the doc library, they're showing up in the group to which I thought I just broke permissions inheritance.

In other words, they're still connected.

A sysadmin said, that is how it's supposed to work.

WTF? Help, please?

Only thing I can say is after working at a company that used Sharepoint, I literally don't understand why any company would use it. 

I thought maybe it was just because I'm not a computer person. Glad to know it sucks for other people too. I have trouble paying a vendor because it keeps trying to get an approval from an old manager even though I've updated my manager repeatedly. They don't know why it keeps doing that or how to fix it. 

I can't just come in and grouse about how it's the sort of thing that businesses adopt in the mistaken belief that they can easily get software done by non-software people without also trying to help. I've never worked with it, but have a good friend who's been venting about it, and I've got a software background. So...

With that said, it looks to me like what happens is that when you break inheritance, the existing groups retain their existing permission. You can modify the group by adding or removing people, but it remains true that anybody in that group has the group's permissions. You have to stop inheriting, and then you need to set up new group(s) to manage access to the orphaned site. If at your current point you gave a new group access to the parent site, *that* would not be inherited.

That is, if I say that all GRM members have access to the Cool Mechanics Club, and members of the Cool Mechanics Club can raid my fridge, if I break Cool Mechanics Club's inheritance from GRM, I still have the copied over rules that the group "GRM members" can raid my fridge. If I add The Big Lebowski to GRM members, I'll be out of vodka and half and half very quickly. To prevent that, I need to stop inheriting from GRM members, and then also set up a separate Reasonable Imbibers group who I'll allow access to Cool Mechanics Club and thus allow to raid my fridge. It doesn't matter that The Dude was added after inheritance was broken, because inheritance was the group GRM members, not the list of people in GRM Members.

So the process is more or less:

1. Stop inheriting permissions
2. Create new groups for whom you will set permissions for the site which no longer inherits permissions
3. Remove the old groups from the newly-separately-permissioned site.

This video isn't great, but it does point out that series of steps:

@Jessi -- thanks for taking the time to respond and for the link, plus a summary. A strong, virtual white Russian to you.

While the example is analogous but a little different, it's nonetheless useful. What I'm seeing is, the video for breaking inheritance for a site -- not a doc library, as I need to do -- shows a UX that actually tells the user what's going to happen and what's recommended. Whereas the info I get from SP (and per MSFT's online documentation) when I'm trying to break doc library inheritance literally says that things will happen and I can do other things. But they don't, and I can't.

PS Our org is balls-deep in MSFT. And we use SharePoint because the work we do on docs is massively collaborative, both internally and externally, so we must have Office-app coauthoring. Plus nearly all of our clients are "enjoying" the MSFT ecosystem, too...

PPS Ask me about the 4 hours I wasted this week trying to figure out why an Excel function wouldn't work: because of a berkeleying bug due to space in a sheet name. Or the time I spent dozens of hours creating essentially a regex lookup table with hundreds of find/replace pairs to programmatically feed through Word's wildcard feature that didn't work in testing because of a known bug that I learned went back to 2007. It is STILL not fixed. Actually, don't ask me about anything having to do with MSFT. berkeley that company.

I don't have the same microsoft environment as you but the concept of groups versus TEAMS members versus SharePoint members has evolved over the pandemic and then the last few months as well. 

I have twice had to basically demolish (couldn't just modify what i had) and reconstruct all the links between groups and document locations. The final form ignores the outlook group functions and tries to exist only in Sharepoint/Teams. The workspace moves away from email based communication to Teams based which is difficult for history tracking. I can see that adding in groups may be getting more stable but it would maybe require another cycle of demolition and rebuilding. 

As an aside I think sharepoint/teams/power suite, may actually be the very expensive but more stable path if you have money and time to build and deploy it. Especially as it seems you need to bring over legacy data. 

In reply to procainestart :

In 2012, my first job post college was as an intern in the vendor management office for State Farm Bank. About half of my job was spent migrating from our servers to share point. Our oldest vendor, with whom we had hundreds if not thousands of contracts, had an ampersand in their name. 
 

Sharepoint, at least at that time, did not allow ampersands in the name of a file or document. 
 

Back then I searched google and asked some people how to do a ctrl+h for file names and it wasn't possible, or I didn't have enough systems access to do it. So I had to manually change all of those file names, changing "&" to "and".

I'm prepending the observation that Advan046's observations make it sound all the more likely that stuff is just b0rken and "correct behavior" may not be achievable without some of that demolition, but as long as I've written it...

EDIT: PreS (like a PostScript but before); I just saw an article on working around the inability to break inheritance because of the number of items in a Library. I'm suddenly nauseated over the sheer opportunity for weird behavior in SP, and am mostly assuming that the below is not useful because SP is just doing something awful that has nothing to do with the logic of permissions...

What's that quote? "I'd have written you a shorter letter but I didn't have time." TL;DR for the below: I still don't see where separate groups are being created. Re-reading the initial post, it still just sounds like the Document Library goes from saying "let whoever has access to the Site in" to "let the group who had access to the Site when we broke inheritance in." And that's just the same group, referenced from both places.

The loooong version. So many apologies:

Sorry it wasn't more directly applicable; I just re-read your initial post. I'm confused because it doesn't sound to me like you're creating a new Group, and I don't see an operation which would create a separate Group for the Document Library (unless this is one of those things that's intrinsic to Doc Library inheritance breaking, but the idea of generating random new groups automatically gives me the heebie jeebies). I don't know what the text is that you're referencing that's being contradictory about what to expect, but what you're explaining is consistent to me with the notion of Groups in a general access and permissions way (it's a concept that comes up a lot regardless of platform).

It's entirely possible that I'm failing to understand something (make that "probable" and "a lot of things"), but it looks to me like you've got Group A that has permissions for the Site, and from the Site inherits permissions to the Library (before you break inheritance). When you break inheritance, you now have independently the facts that Group A has permission to the Site, and that Group A has permissions to the Library because it got its own copy of the permissions it had at the time of breaking inheritance, but Group A is still Group A, and if you add someone to Group A, they show up in both places because it is still just the one Group. That is, they're not "still connected," they're actually the same group. It's just that in the Library it's got its own copy of the directive to "let Group A in" instead of inheriting "let whoever can get into the Site in."

You can remove Group A's permission to the Library, and you can add Group B's permission to the Library and then only Group B would have access to the Library. You could add Group C to the Site and it would not automatically get access to the Library because you've broken inheritance. Users within those groups will always have the permissions of the group, and can be added or removed from the groups and will gain and lose the group permissions when that happens.

I have the terrible feeling that I'm trying hard to explain something you already know while I'm missing the part that means I've missed the point...

I also realize I sounded pretty dismissive of working with SP, and that was sloppy, inaccurate, and inappropriate. Wrestling with stuff like SP is miserable, and I think it's a rough gig to get stuck with all the "real" software problems and only SP to fix them with. It seems to be a terrible tool, and my aggravation is just with the business notion that you can just get a tool that doesn't require "writing code" and it can just be a part of another job. I tend to dislike frameworks because you get stuck having just as much trouble learning them as you would a programming language, and all the complexity that's supposed to make things easy invariably ends up making unusual use cases harder and problems harder to find and fix. In any case, my respect and heartfelt sympathies for folks stuck wrangling SP.

Jesse Ransom said:

It's entirely possible that I'm failing to understand something (make that "probable" and "a lot of things")."

You're understanding it. The site has discrete collections of users (i.e., SharePoint groups) with certain permissions, and the doc library inherits the SharePoint groups' permissions. When you break permissions inheritance in the document library, the UI says you've now made exact copies of the SharePoint groups that controls document library access, and other documentation says that if you change either the originals, it won't affect the doc-library clones. And by that logic, that should work both ways: you can't change the clones and affect the original site-level groups.

But it's not working the way I'd expect it to, based on what SP tells me.

So, yes, in the end, the group membership actually remains linked--the doc library instances are not, technically, copies--but what I can do is change the library instance's permissions, from, say, Edit to Read-only.

More fun: I'm developing a training program that shifts responsibility for dealing with this stuff from IT to our users. No one agreed with me that that would be a Bad Idea. They might change their mind when they get a call from an angry project manager whose client is irate because we allowed an adversarial collaborator access to content that they absolutely should not be able to see. Or, worse, we get a call from a an angry client's lawyer...

In reply to mtn :

That sounds like hell, frankly. :-(

In reply to Advan046 :

See my comment elsewhere about being balls-deep in MSFT. SharePoint/Teams/PowerApps is our new jam. Really, the only good thing so far is PowerApps. I'm not a professional coder, but I know enough to be able to achieve pretty useful things with Power Automate.

In reply to procainestart :

I think it's possible that the most broken part is the way they've phrased it.

Everything else seems to be consistent with the idea that it's just one group, but after breaking inheritance that group's relationship to the site and to the library are managed separately.

I was looking for a little more info and found your post over on a msft forum, where you were a little more verbose about the messages from the UI, and I would still readily take that to mean that on breaking inheritance the list of groups and those groups' permissions are copied over. It would seem that you should be able to adjust the site and library permissions for that group separately, but it's still the same group.

If you've got a group of people who don't all have the same permissions as each other in both places, you'd need to explicitly create a new group.

In reply to procainestart :

Ok how I tried to explain it to my new chief, after explaining that it isn't my job to do any of it, was that deploying the new MS environment is not a choice at our level it was made way above our heads. But what the MS environmental methodology requires is that we meet halfway in the change of how we work internally and outward facing. Document library permissions change with relatively fixed outlook groups may be a thing of the past. Instead the people who have access are constantly having to be refreshed via timed obliteration of groups/teams so almost need to regenerate a new access list every cycle which can be driven by a well maintained Active Directory or similar product. 

I am seeing similarity of the MSFT with Lotus Notes...Lotus became too versatile as if it was becoming a programming language versus a tool to aid permissions and automate work with preset, and limited, modules.

So in the end I said to him, "So back in the day of mechanical typewriters, eventually if you have to revise the report too much you stopped with white out and overwrite carbon and just re typed the darn thing from scratch. Same with this digital landscape. At some point, we have to stop trying to adapt a google based system that was adapted from Lotus Notes and just start from scratch."

@Jessi -- Yes, exactly what you wrote: "...the most broken part is the way they've phrased it."

@Advan046 -- Nontechnical people will be responsible for periodic access review, via a 3rd-party governance tool. Other nontechnical people will be responsible for day-to-day management (hence my post--I have to train them).

I recently saw a t-shirt that said: "No, you're right -- let's do it the dumbest way possible, because it's easier for you." That's the core of this project...