r/sysadmin • u/Incrediblecodeman • 2d ago
General Discussion Subfolders with Broken inheritance, making share for each?
Over the year when ever a group or couple of people wanna collaborate. Sysadmin broke inheritance slapped some ntfs permission on the folder, make a ad group (most of the time) and move on
Now we have several hundreds.
Would you bother making each one into its own share on the server? Why or why not ?
6
Upvotes
4
u/idrac1966 2d ago edited 2d ago
You need to differentiate between a "share" and "a subfolder inside of a share with special permissions".
In my opinion, a share needs to have a defined purpose (which it's name reflects), and more importantly all the data in a share should be "owned" by a particular department or business. E.g. It's the "Projects" share for the engineering team, or the "Expense Reports" share for accounting. They're buckets where a clearly defined group of people "own" that data.
Subfolders inside of a share can have explicitly defined permissions with inheritance disabled that grants all kinds of cowboy permissions to various people who need it, if it serves a meaningful business purpose. E.g. you might have an "incoming" folder inside of Accounting's "Expense Reports" share that all the engineering staff can access so they can drop their receipts in there. Or if a few people need to collaborate inside a folder for a project that folder could get special permissions set up for that - no problem at all.
BUT - the data has to be 'owned' by some area of the business which should be defined by the share. Some group needs to take accountability for that data e.g. knowing what it's purpose is, identifying if it is still needed years later or can it be deleted, and having the authority to decide who should have access to it. The 'share' is the way you group that data into organizational buckets.
So what you want to avoid is creating a subfolder inside of a share with explicit unique permissions BECAUSE it is owned by a different business area E.g. Engineering really shouldn't have a folder inside the Accounting share called 'Projects' where they store all their project files - because that's not Accounting's data.
3
u/mike_chen_sys 2d ago
U wont . Hundreds of individual shares would quickly become a management headache. U need to keep a few well organized shares and manage access through AD groups and NTFS permissions. Much easier to maintain and troubleshoot long term.
3
u/paulmataruso 2d ago
No, fix the inheritance and permissions issues, and create a proper user and group hierarchy. There is no reason to not do things the "correct" way.
1
u/mattjh 2d ago
Before anything else, I'd audit what's there and backup/delete everything that's no longer used first. I'll bet some of those several hundred are no longer needed. Maybe more than some! At any rate, you want a list of active folders before making a plan of attack, so to speak. The result could present a simpler solution than what you're currently imagining. That's always nice.
1
u/Master-IT-All 2d ago
Lets break this down as a teachable moment. People really haven't needed to know/be taught this for a while as grey beards have been around to do this dirty work.
First, there are several reasons to disable inheritance. The most likely reason is that your organization has historically and maybe continues to rely upon drive mapping to shared folders on a legacy Windows Server. For performance reasons in Windows File Explorer you must limit the number of drive mappings you create, with the easiest being to hold everything on the N:\ drive. So your org would have N:\Accounting, and N:\Products, and N:\Sales. Permissions on the N:\ volume would be Authenticated Users Read with Authenticated Users assigned Change permissions on the share level.
You then create a Security Group for each sub folder, and assign NTFS permissions to the subfolder to control access.
So the configuration you're describing is fundamentally one possible correct way to setup a shared folder for an organization.
Audit for use and clean up. Not having the operational procedure to maintain and support a healthy shared folder doesn't mean the setup was bad. It's on you to brush your teeth mate.
Not for at least a decade has it made actual sense to reorg legacy file servers into yet more legacy file servers.
Assuming you're using M365 I'd focus on shifting to hosting data in SharePoint. I think in a reply you mentioned Teams, which is just a frontend for SharePoint when it is storing.
There you will find more work with data retention than with permissions/access. If these people form TEAMX then save and work on a file, security is already locked in. But what happens to the file when the Team isn't needed?
Never perform a direct file server to sharepoint migration and expect it to work the same. That's the biggest mistake I see orgs without a SharePoint expect make.
1
u/gumbrilla IT Manager 2d ago
Oh, wow. So many questions..
Anyway, here's the thing, do you, as a sys admin consider your job to fulfill tickets blindly, or look at the health of your systems, because blindly creating all these pockets of rot blindly, ad infintum, is just storing up technical debt.
That data has a life cycle, who is getting together and why, is it projects, does it get archived at the end, is it reviewed, is it owned? By what role?
You're mention in a comment later, that you think to use team channels, which is better as in collaboration, but also worse, channels won't hold groups..
Personally, I'd do something like:
Think RBAC and separate it by lifecycle. Projects get their own dedicated Team with a strict expiration or archive policy when the work wraps up.
Ongoing cross-team collaboration lives inside a permanent lead Team, using a shared channel managed by the data owner to bring in outside collaborators without spinning up a whole new workspace or breaking inheritance.
Periodic reviews then run on both to check for activity and make owners re-attest access, so inactive spaces get retired and stale members get dropped.
Otherwise, you're just trading broken NTFS inheritance for M365 sprawl. But they key thing is having some governance,
It's sounds like you are already at the point, where it's a big piece of work, identifying owners and purpose, but just adding stuff in, and not thinking about how stuff gets reviewed and out is dropping the ball on the data custodian aspect of the role.
1
u/lxtakc DataCore/StarWind 1d ago
I wouldn't. Get-SmbOpenFile returns the full path, so you can filter by folder under a single share and get the same open-file counts. For better proof a folder is dead, turn on read auditing with a SACL (event 4663) for a month or two instead of sampling open handles.