NTFS permissions, share permissions, and working out which one wins

Why this matters

Permissions are where a fair number of technicians quietly guess, and the exam knows it. There are two sets of them, they interact in a specific way, and the result is frequently the opposite of what the person configuring it expected.

The good news is that the rules are short and mechanical. Once you can work out an effective permission on paper, the scenario questions become arithmetic rather than intuition — and, more usefully, so do the real ones, where somebody cannot open a file they are certain they have been given access to.

This lesson is the applied lab for its objective for that reason: the only way to be sure you have the rules is to set them up and watch them behave.

The lesson

The two permission sets, where each applies, and why both exist

Two permission sets exist because they were designed for two different questions.

NTFS permissions belong to the file system. They apply however the file is reached — locally, over the network, by a service, by a scheduled task. They are granular: read, write, modify, full control, and a long list of advanced rights beneath those. They apply to files as well as folders.

Share permissions belong to the share. They apply only to access over the network, they are coarse — read, change, full control — and they apply to the share as a whole. A user sitting at the machine is entirely unaffected by them.

Both exist for a historical reason that still matters: share permissions predate NTFS and work on file systems that have no permissions of their own. A FAT32 volume shared over the network can only be protected by share permissions, because there is nowhere in the file system to record anything else.

The consequence for how they are used today, and it is the standard practice worth recommending: set the share permission once, generously — usually Everyone: Full Control or Authenticated Users: Full Control — and do all the real work in NTFS. That gives one place to look, one set of rules to reason about, and behaviour that is the same locally and remotely. Configuring both sets is how estates end up with permissions nobody can explain.

Inheritance, explicit entries, and why a deny is not always final

Inheritance is what makes permissions manageable and also what makes them surprising.

Inheritance means a folder's permissions flow down to everything inside it. Setting a permission at the top of a tree is how you set it for a thousand files, and it is why permissions are set on folders rather than on files.

Explicit entries are set directly on an object. They take precedence over inherited ones, and this is the rule that makes the rest work.

The order of evaluation, which is the examinable part:

1. Explicit deny — wins over everything at this level.
2. Explicit allow.
3. Inherited deny.
4. Inherited allow.

Why a deny is not always final: an inherited deny is beaten by an explicit allow further down. So a folder that denies a group, containing a subfolder that explicitly allows a member of that group, grants access — the explicit entry at the lower level outranks the inherited one from above. That is the mechanism behind "the permissions say no and it works anyway", and it is a stock exam question.

Two practical notes. Deny is a tool of last resort: permissions are additive from group membership, and a single deny can be very hard to find later when someone is mysteriously refused. Prefer removing an allow to adding a deny. And when you break inheritance, Windows asks whether to copy the inherited entries or remove them — copying converts them to explicit entries, which is usually what you want and which also means they will no longer track changes made above.

The effective permission: the more restrictive of share and NTFS, worked through

The rule is short: the effective permission over the network is the more restrictive of the share permission and the NTFS permission. Locally, share permissions do not apply at all.

Within each set, permissions from multiple group memberships are cumulative — a user in two groups gets the union of what both allow — and then any deny that applies removes it.

Worked through. A folder \\SERVER\Projects:

• Share permission: Everyone: Read
• NTFS permissions: Project-Team: Modify, Managers: Full Control

Alice is in Project-Team. Over the network:

• NTFS gives her Modify.
• The share gives Read.
• More restrictive wins: Alice has Read. She will report that she cannot save changes, and every NTFS permission she can see says Modify — which is exactly the confusion this rule creates.

Sitting at the server, Alice has Modify, because the share is not involved.

Second case. Share: Everyone: Full Control. NTFS: Project-Team: Modify, Contractors: Deny Write. Bob is in both groups.

• Cumulative NTFS allow: Modify.
• Deny Write applies: Bob can read and cannot write, locally and remotely.

The method for any question of this shape: work out the NTFS result from all group memberships, apply any denies, then take the more restrictive of that and the share — and only if the access is over the network.

Moving against copying, and the permissions that change under your hands

This is the behaviour that changes permissions when nobody meant to change anything, and it is worth memorising because it is short.

Within the same NTFS volume:

• Move — the file keeps its existing permissions. Nothing changes.
• Copy — the new copy inherits the destination's permissions.

Between different NTFS volumes:

• Both move and copy behave as a copy: the file inherits the destination's permissions. A move between volumes is a copy followed by a delete, which is why.

To a file system with no permissions — FAT32, exFAT, most memory sticks — permissions are discarded entirely, because there is nowhere to record them.

The rule in one sentence: permissions survive only a move within the same volume; everything else inherits the destination.

Two consequences that matter in real work. A carefully restricted folder copied "as a backup" into a general area becomes readable by whoever can read that area — and the person who did it believes the restrictions travelled. And a sensitive file copied to a USB stick has no permissions at all, which is one of the reasons encryption and removable-media policy exist.

The other half of the same idea: ownership. The owner of a file can always change its permissions regardless of what those permissions say, and an administrator can take ownership. That is the escape hatch for a folder nobody can access — and it is also why ownership matters as much as the permission list.

Auditing access to a folder, and reading what the log actually says

Auditing records who did what, and it is off by default because it produces a lot of events.

Turning it on has two halves, and missing either produces nothing:

1. Enable the audit policy — object access auditing, through local or group policy.
2. Set an audit entry on the folder, in its advanced security settings, naming which principals and which kinds of access to record.

Then the events appear in the Security log in Event Viewer.

Reading what the log actually says, which is the part people find disappointing:

• Events record access attempts, both successful and failed, according to what you asked for. Auditing success on a busy folder produces enormous volume.
• An event names the account, the object, the access requested and the process. It does not tell you what the user did with the file afterwards — reading a file and copying it look identical.
• A failure event is the most useful kind for troubleshooting: it says exactly which account was refused which access to which object, which turns a permissions puzzle into a fact.

Two practical points. Audit failures first when diagnosing, because the volume is manageable and the information is direct. And be aware that enabling success auditing broadly can fill the log and push out older events, so the retention settings matter — a log that has rolled over is a log that cannot answer the question you are about to ask it.