Shared drives and permissions

Every helpdesk queue has a steady drip of the same ticket: "I can't open the file." The answer almost never lives where the ticket creator thinks it does — it lives in the interaction between two separate access-control lists, plus a user who's in four groups, plus an explicit deny buried on one folder three levels up. This lesson is the mental model that lets you resolve those tickets in thirty seconds instead of thirty minutes.

The two-layer rule

On every real file-share system — Windows SMB+NTFS, macOS POSIX+ACLs, Google Drive's sharing vs. parent-folder model, even modern cloud stores — access is gated by two independent ACLs stacked on top of each other:

• Share ACL — the network-layer permissions. This is what the file server exposes over the wire. On Windows this is the "Share permissions" tab; on macOS SMB shares this is sharing -s; on Google Drive this is the "Who has access?" dialog on the container.
• Filesystem ACL — the on-disk permissions. This is NTFS on Windows, POSIX mode bits + optional ACLs on macOS/Linux, and for cloud drives it's the per-object ACL enforced by the storage backend once the share has been entered.

The effective permission is the intersection of the two — the weaker grant wins. If the share says "read" and NTFS says "write," you get read. This is the one rule that resolves the majority of "why can't Alice open the file?" tickets: somebody has cranked one layer wide open and forgotten the other exists.

Deny beats allow

Every ACL is a list of Access Control Entries (ACEs). Each ACE is one of two kinds:

• Allow — "this principal gets this permission."
• Deny — "this principal is explicitly blocked, regardless of anything else."

The resolution rule is universal across Windows DACLs, POSIX ACLs, and cloud sharing models: deny beats allow. If any matching deny ACE fires anywhere in either ACL, the request is blocked. It doesn't matter how many "allow" ACEs grant the principal full control through group membership — one matching deny shuts the whole thing down.

This is how administrators temporarily block a specific user from a shared folder without having to pull them out of every group they're in. It's also how accidents happen: an explicit deny on a group the user is also in will silently lock them out of everything that group touches, and the user will have no idea why. The typical helpdesk symptom is "I had access yesterday and now I don't" — check for a new deny ACE added at a parent object.

Group inheritance

Users almost never hold permissions directly. They hold group memberships, and ACEs are written against groups. Alice is in marketing; marketing has an allow-read ACE on the share; therefore Alice can read.

The gotcha is that users are usually in many groups, and ACEs can resolve differently per group. Bob is in both staff (read-only) and admins (full control). Both allow ACEs match; the resolver picks the strongest allow (full) per layer, then intersects the two layers. The mental shortcut: to figure out what a user sees, walk their group list and collect every matching ACE — then apply deny-beats-allow first, and intersection second.

Effective-permission resolution, step by step

Given a user, a share ACL, and an FS ACL:

1. Filter the ACEs to those that match the user. An ACE matches if its principal is the user's id directly, or if it's one of the user's groups. Everything else is irrelevant.
2. Check for any matching deny ACE. If one exists on either layer, the answer is deny. Done.
3. For each layer independently, pick the strongest matching allow. full > write > read. If a layer has no matching allow, its grant for this user is none.
4. Intersect the two layer grants. If either is none, the answer is none. Otherwise the answer is the weaker of the two.

The playground on the next tab runs exactly this algorithm. The visualizer draws the tree — user → groups → ACEs → result — and highlights the winning ACE so you can see which rule "decided" the outcome.

The "Everyone: Full Control at share but locked-down NTFS" trap

This is the single most common misconfiguration in small-to-medium-business file servers, and it's worth memorising on its own. The Windows default on a freshly-created share was (until very recently) to grant Everyone: Full Control at the share layer, leaving all the real enforcement to NTFS at the filesystem layer. Administrators who don't know the two-layer rule look at "Everyone: Full Control," panic, and lock the share down to a specific group — breaking access for anyone outside that group even though NTFS on the folder would have allowed them. Or they do the reverse: lock the share down to Everyone: Read thinking it's safe, then grant full NTFS write to their team, and can't figure out why nobody can save.

The fix is always the same: audit both layers together. A modern recommendation is to lock the share to the loosest grant the business requires (Authenticated Users: Full Control) and do all granular control at the NTFS layer, because NTFS supports per-user ACEs, inheritance, and auditing — share permissions don't.

Real products, same abstractions

The model above isn't specific to Windows. Each product dresses it up differently, but the two-layer + deny-beats-allow + intersection model survives:

• Windows (SMB + NTFS) — two explicit ACLs, resolved exactly as described. Inheritance flags control whether an ACE propagates to child objects.
• macOS (POSIX + ACLs) — POSIX mode bits (rwxrwxrwx) act as a coarse first layer; extended ACLs (the + in ls -le) add a second fine-grained layer that can grant or deny beyond what POSIX allows.
• Google Drive / Google Workspace — the parent folder's sharing rules and the file's own explicit sharing are the two layers; the most restrictive wins. An "Anyone with link" file in a "Domain-only" folder is only accessible to the domain.
• OneDrive / SharePoint — site-level, library-level, and item-level permissions stack in the same way; inheritance is explicit and can be broken.
• Dropbox, Box, and similar — team folder permissions are one layer, per-file sharing is a second; team folder settings override individual file grants.

Common gotchas

• Inheritance drift — someone breaks inheritance on a subfolder to add one permission, and three years later nobody knows why that folder doesn't match the parent.
• "Works on the server console" bug — admins RDP'd into the file server bypass the share ACL entirely (they're accessing via the local filesystem), so "it works for me" tells you nothing about what a network user sees.
• Stale group membership — a user whose groups were changed needs to log out and back in before the new membership is in their session token; adding a group and saying "try now" without a logout will look like the ACL isn't working.
• Explicit deny on a widely-used group — an explicit deny on Authenticated Users or Domain Users locks out most of the org in one step.
• Cloud-drive parent traps — a file that looks shared "with the whole team" in its own dialog is actually blocked because a parent folder is restricted.

Playground

Pick a scenario, edit the user's groups, mutate either ACL, and watch the effective permission update live. Try the CEO over-share trap first: the share says "Everyone: Full" but NTFS says "Finance: Full" — a marketing employee gets no access, because the filesystem layer denies by default to anyone not listed.

Visualizer

The resolution tree draws the user, their groups, every ACE on both layers, and the final effective permission. Edges from matching principals to matching ACEs are drawn in the accent color; the winning ACE — the one that actually "decided" the outcome — is highlighted in bold.