You can open a file when you're on the PC, but the same file fails from a shared folder, even though you "gave everyone access." Or an app installs only when you right-click and choose Run as administrator. These are common support tickets, and they map directly to CompTIA A+ Core 2 (220-1202), Domain 2, Objective 2.2.
Windows access control often comes down to two layers that interact in ways people miss: NTFS permissions and share permissions. Add file and folder attributes, plus inheritance, and a simple change can spread (or not spread) across a directory. As a result, you can end up with the right setting in the wrong place, or the wrong setting that overrides everything else.
By the end of this post, you'll be able to compare NTFS vs. share permissions, explain inheritance and attributes in plain terms, and choose the right approach between a standard user, Run as administrator, and User Account Control (UAC) prompts. You'll also know what to check first when access works locally but fails over the network.
Local vs Network Access
For CompTIA A+ Core 2 (220-1202), Domain 2, Objective 2.2, the key idea is simple: Windows checks different permission layers depending on how you reach a file. When you open a folder while signed in at the PC, you mostly deal with NTFS permissions. When you open that same folder through a shared path over the network, Windows applies share permissions plus NTFS, and your final access can shrink fast.
Think of it like two doors. Local access goes through one door (NTFS). Network access goes through two doors (share, then NTFS). If either door blocks you, you stop there.
NTFS permissions in plain terms (who can do what on a folder)
NTFS permissions control access to files and folders stored on NTFS-formatted drives. If the drive is FAT32 or exFAT, you won't get the same NTFS security controls. In practice, NTFS permissions answer: "What can this account do in this folder, right here on disk?"
Most users see a small set of permission names. Here is what they mean in day-to-day work:
- Read: You can open files, view folder contents, and run programs. However, you can't change file contents or save over a file.
- Write: You can create new files and folders, and you can change some file data. Still, Write alone can surprise people because it doesn't always include delete rights.
- Modify: You can read, write, and delete, and you can change existing files. For many data folders, Modify is the practical "can work here" permission.
- Full control: You can do everything in Modify, plus change permissions and take ownership. This is powerful, so admins usually reserve it for IT and service accounts.
A quick way to map this to common tasks is to think in verbs:
- Open and view maps to Read.
- Create and save new files often maps to Write (and sometimes also needs Modify, depending on the app).
- Edit and replace files usually needs Modify.
- Delete files or folders typically requires Modify (or higher).
- Change who has access requires Full control.
Another detail matters: Allow vs. Deny. Windows builds your effective permissions from group memberships and explicit entries. An explicit Deny can override many Allows, so it can block access even when everything "looks" correct.
Use Deny sparingly. It's easy to forget later, and it can block admins and support accounts during troubleshooting.
In most cases, you get cleaner results by granting the right Allow permissions to the right groups, then removing what you don't want, instead of adding Deny entries everywhere.
Share permissions in plain terms (who can use the share)
Share permissions apply only when you access files over the network through a shared folder. They answer a different question: "What can a network user do through this share name?"
Common share permission levels are:
- Read: Network users can view folder contents and open files. They can't change data or delete.
- Change: Network users can read, create, edit, and delete files and folders in the share.
- Full control: Network users can do everything, including changing share permissions.
The big gotcha is scope. Share permissions do not apply when a user is logged on locally and accesses the folder through a local path such as C:\Data. They apply when the user uses a UNC path such as \\PCName\ShareName (or maps a drive to that share).
Because share permissions are a second layer, many admins keep them simple. A common approach is:
- Set share permissions broad (often Change or Full control for a trusted group).
- Control real access using NTFS permissions on the folder.
That pattern stays popular for a few practical reasons. First, it gives one consistent control point (NTFS) whether users connect from their desk, a remote session, or another tool that still hits NTFS. Second, NTFS permissions tend to support clearer auditing and review, because the folder's security tab shows who can do what at the file system level.
Still, share permissions have a place. They can provide a fast "front gate" for network access. For example, you might give only a certain group any share access at all, even before NTFS comes into play.
When NTFS and share permissions collide, the most restrictive wins
When you access a folder over the network, Windows combines the two layers. The effective permission is the most restrictive result of share permissions and NTFS permissions. In other words, you only get what both layers allow.
Here are a few quick examples that mirror real help desk cases:
- Share = Read, NTFS = Modify → effective access is Read over the network (the share blocks writes and deletes).
- Share = Change, NTFS = Read → effective access is Read over the network (NTFS blocks edits and deletes).
- Share = Full control, NTFS = Modify → effective access is Modify over the network (NTFS still limits permission changes).
This rule explains why "I gave them Modify" can still fail from a mapped drive. If the share is set to Read, network users stay stuck at Read.
Bottom line: for network access, share permissions can only reduce access, not increase what NTFS already allows.
When something doesn't add up, use a short, repeatable troubleshooting flow:
- Confirm the path used: Are you testing
C:\Folder(local) or\\Server\Share(network)? Results can differ. - Check group membership: The user may belong to a group that grants access, or a group that restricts it.
- Look for explicit Deny: Even one Deny entry can block expected access.
- Test with a different account: Compare behavior with a known-good user to isolate whether it's user-specific or folder-wide.
If you apply that list in order, you avoid chasing the wrong layer. Most permission issues come down to testing the wrong path, missing a group, or forgetting that the share layer still exists.
Attributes and Inheritance
For CompTIA A+ Core 2 (220-1202), Domain 2, Objective 2.2, you need to separate what Windows labels on a file from what Windows allows you to do with it. Attributes and inheritance often create "surprise" permission outcomes because they sit next to NTFS permissions in the user interface, yet they behave very differently. If you treat an attribute like a security control, or forget that a parent folder can rewrite access down the tree, troubleshooting gets messy fast.
A good mental model helps: attributes are sticky notes, while permissions are locks. Sticky notes may change how something looks or behaves, but they do not decide who gets in.
File and folder attributes you should recognize fast
Windows file attributes are simple flags stored with the file or folder. They can change how items display, how some apps behave, or how backup tools track changes. However, attributes are not security permissions, so they do not grant or deny access by themselves.
Here are the common ones you should recognize quickly:
- Read-only: Signals that a file should not be modified. Many programs respect it and refuse to save changes, or they prompt to save a copy. Still, if NTFS permissions allow writing, some tools can remove the attribute and write anyway. On folders, Read-only often confuses people because it can reflect folder customization settings, not a true "lock."
- Hidden: Hides the item from normal views in File Explorer.