This is the final episode of the TrevTech homelab series. We’ve built Active Directory, automated it with PowerShell, locked it down with Group Policy, and configured DNS and DHCP. Now we’re adding the last piece: a file server with proper permissions.
File shares are one of those things that looks simple until it isn’t. Most environments I’ve seen in the real world have file shares that were set up years ago, have accumulated permissions like barnacles, and nobody quite knows who can access what or why. We’re doing it right from the start.
Why Get Permissions Right?
Because wrong permissions are either a security problem or an operational problem — and usually both.
Too permissive: users can see files they shouldn’t. Audit fails. Data leaked. Difficult conversations with management.
Too restrictive: users can’t access what they need. Help desk tickets pile up. Nobody can do their job.
The goal is a permissions structure where access is predictable, manageable, and driven by group membership — not by whoever the sysadmin was in the mood to trust on the day the share was created.
The Lab Context
| Detail | Value |
|---|---|
| Domain | trevtech.lab |
| File Server | DC01 acting as file server (lab only) |
| Share path | \\DC01\SharedDocs |
| Drive map | S: drive (configured via GPO in Episode 3) |
| Clients | 2 x Windows 11 VMs, domain-joined |
In a real environment the file server would be a separate machine from the DC. In the lab, DC01 is doing everything — that’s fine for learning.
Understanding the Two Permission Layers
This is the part that trips people up. File shares in Windows have two separate permission layers, and both have to be right.
Share Permissions — set when you share the folder. Controls access over the network. Options: Read, Change, Full Control. Best practice: set Share Permissions to “Everyone — Full Control” and let NTFS permissions do the real work.
NTFS Permissions — set on the folder itself. Apply whether you’re accessing the folder over the network or locally. These are the permissions that matter. They’re also the ones that get complicated.
The principle: Share Permissions open the door. NTFS Permissions control the rooms.
If a user’s effective permission is “Read” in NTFS but “Full Control” in share permissions, they get Read. The more restrictive of the two always wins.
The Folder Structure
For trevtech.lab, I set up a shared folder structure under D:\Shares\:
D:\Shares\
├── SharedDocs\ ← Shared as \\DC01\SharedDocs (the S: drive)
│ ├── IT\ ← IT department only
│ ├── Finance\ ← Finance department only
│ ├── HR\ ← HR department only
│ └── Common\ ← All staff, read/writeEach department folder is locked to the corresponding AD security group (IT-Users, Finance-Users, HR-Users). The Common folder is accessible to all domain users.
Setting NTFS Permissions
Here’s the PowerShell approach. Setting permissions via the GUI works but doesn’t scale — and you can’t audit or reproduce a GUI click.
# Disable permission inheritance on a folder (take ownership of the ACL)
$acl = Get-Acl "D:\Shares\SharedDocs\IT"
$acl.SetAccessRuleProtection($true, $false) # block inheritance, remove inherited entries
# Grant IT-Users group Read & Execute + Modify
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"TREVTECH\IT-Users",
"Modify",
"ContainerInherit,ObjectInherit",
"None",
"Allow"
)
$acl.SetAccessRule($rule)
Set-Acl -Path "D:\Shares\SharedDocs\IT" -AclObject $acl
# Grant Domain Admins Full Control
$adminRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"TREVTECH\Domain Admins",
"FullControl",
"ContainerInherit,ObjectInherit",
"None",
"Allow"
)
$acl.SetAccessRule($adminRule)
Set-Acl -Path "D:\Shares\SharedDocs\IT" -AclObject $aclAnd the share itself:
# Create the share with Share Permissions wide open (NTFS does the real work)
New-SmbShare `
-Name "SharedDocs" `
-Path "D:\Shares\SharedDocs" `
-FullAccess "Everyone" `
-Description "trevtech.lab shared documents"Testing Access
After setting everything up, I tested with each department’s test user account:
jsmith(IT-Users) → can access IT folder, blocked from Finance and HRadoe(Finance-Users) → can access Finance folder, blocked from IT and HRCommonfolder → all three users can read and write
The icacls command is useful for a quick audit:
# Check effective permissions on a folder
icacls "D:\Shares\SharedDocs\Finance"
# Check what access a specific user has
Get-Acl "D:\Shares\SharedDocs\Finance" | Format-ListThe Gotchas
Inherited permissions are sneaky. When you create a subfolder, it inherits permissions from the parent. If you forget to break inheritance before setting department-level permissions, users will still have access they shouldn’t. Always disable inheritance first on folders that need locked-down access.
CREATOR OWNER and SYSTEM. When you look at the ACL on a new folder, you’ll see CREATOR OWNER and SYSTEM already there. Leave them. CREATOR OWNER means whoever creates a file in the folder gets ownership — that’s expected behaviour. SYSTEM needs access to the filesystem for various OS operations.
Group membership changes don’t take effect until re-login. If you add a user to a group and they’re already logged in, they won’t get the new permissions until they log out and back in. The Kerberos token is cached at login. In urgent situations, gpupdate /force won’t help here — it’s a logon token issue.
Access Based Enumeration (ABE). By default, users can see all subfolders in a share even if they don’t have access. They’ll just get “Access Denied” when they try to open them. ABE hides folders the user has no access to, which is cleaner and reveals less about your folder structure. Enable it in the SMB share settings.
# Enable Access Based Enumeration on the share
Set-SmbShare -Name "SharedDocs" -FolderEnumerationMode AccessBasedIs It Worth Getting Right?
Yes — and unlike some of the other topics in this series, file permissions have an immediate, visible impact on security.
If you understand NTFS permissions — how they inherit, how they combine, how to audit them — you can clean up any permissions mess you inherit at a new job, build new shares that won’t turn into a mess, and handle access requests without guessing.
It’s also one of the most common areas where junior sysadmins make mistakes that have real consequences. Getting comfortable with this in the homelab first means you’re not figuring it out in production.
Series Wrap-Up
This is the end of the TrevTech homelab series — at least this first one. Over five episodes, we’ve built a real Windows environment from scratch on a $400 Dell R730:
- Active Directory — the foundation
- PowerShell for AD — automation
- Group Policy — management and security
- DNS & DHCP — network services
- File Server & Permissions — secure sharing
trevtech.lab is now a functioning, managed Windows environment. Not a toy. Not a tutorial environment. Something that mirrors what you’d find in a small business.
More series are coming. If there’s a topic you want covered — SCCM, Intune, Proxmox clusters, VLANs — drop it in the comments.
Watch it all on TrevTech-IT on YouTube.
— Trev | I broke it. Fixed it.
