A friend called me last winter in a full panic. He had spent an evening "tidying up" the permissions on his Synology DS220+, and by the time he was done, his wife could not open the family photo folder from her laptop. Every attempt threw the same wall: "You do not have permission to access NASPhotos."
Nothing was broken. He had just made three small, very human mistakes in a row.
That call is basically this whole article. Locking yourself out of a NAS is almost never a hardware fault or a corrupted drive. It is a settings tangle, and once you know where the knots form, you can undo them in about ten minutes. Here are the permission mistakes I see over and over, and exactly how to walk each one back.
Mistake 1: Assuming the share permission and the folder permission are the same thing
This is the big one, and it fools almost everyone the first time. On most NAS boxes there are two separate permission layers stacked on top of each other, and access is the most restrictive of the two.
The first layer is the shared folder permission (Synology calls it "Edit Shared Folder", QNAP calls it the folder's access rights). The second layer is the file-level permission, the Windows ACL that lives inside the folder.
Here is the trap. You can give a user Read/Write at the shared folder level, feel finished, and still get denied because the ACL underneath says No Access. Both gates have to be open. If either one is shut, the user is out.
When someone is denied for no obvious reason, I check both layers before touching anything else. On Synology that means Control Panel, then Shared Folder, then Edit, then the Permissions tab, and separately the folder's Properties inside File Station under the Permission tab.
Mistake 2: Adding a user to a group, then setting an explicit Deny that overrides it
Deny always beats Allow. That single rule causes more lockouts than anything else I run into.
Say you put your wife in the "family" group and give that group Read/Write. Good. But earlier, maybe months ago, you set her individual account to "No Access" on that same folder because you were testing something. That old explicit Deny quietly outranks the group Allow, and she stays locked out no matter how many groups you add her to.
The fix is to hunt down the explicit Deny and clear it. In the permission list, look for a checkbox in the "No Access" column tied to the individual account, not the group. Uncheck it, then re-apply the group permission.
How to tell Allow from Deny at a glance
Most NAS interfaces show a grid: rows are users and groups, columns are Read/Write, Read Only, and No Access. A user can technically have a check in more than one row through group membership. When that happens, No Access wins. Always. Scan that column first.
Mistake 3: Turning off guest access without giving real accounts a way in
Disabling the guest account is good security advice, and I stand by it. The problem is people flip it off and then discover half their devices were quietly relying on guest access the whole time.
Smart TVs, older streaming boxes, and some media players do not handle NAS logins gracefully. They were reaching the share as "guest" and nobody noticed until guest went dark.
You have two clean options. Create a dedicated low-privilege account (I usually call it "media") with Read Only on just the shares those devices need, and enter those credentials on the device. Or, if the device genuinely cannot log in, keep guest enabled but lock it down to Read Only on one specific folder and nothing else.
Mistake 4: Editing the wrong permission model entirely (Windows ACL versus Unix mode)
Synology and QNAP let a share run in different permission modes. Older shares, and anything created for basic Linux or Mac use, may use classic Unix-style permissions (owner, group, others, with rwx bits). Newer shares often use Windows ACL, which is far more granular.
The mistake is fighting the ACL when the share is actually in the simpler mode, or vice versa. You keep ticking boxes that have no effect because you are editing the layer that is not in charge.
Check which model the share uses before you edit. On Synology, the shared folder's Advanced settings tell you whether "Enable Windows ACL" is on. If it is on, edit through the ACL grid. If it is off, the simpler owner/group boxes are what matter.
A quick comparison of where each mistake bites
| Mistake | Typical symptom | Fastest fix |
|---|---|---|
| Share vs folder layer confused | Access denied despite "correct" permission | Open both layers, set both to allow |
| Explicit Deny overrides group | One user blocked, others fine | Clear the individual No Access flag |
| Guest access disabled | TVs and media players lose the share | Add a dedicated Read Only account |
| Wrong permission model edited | Changes have no visible effect | Check ACL on/off, edit correct layer |
| Broken inheritance after a move | New subfolder rejects everyone | Re-apply and propagate from parent |
Mistake 5: Moving a folder and losing inheritance
Permissions usually flow downhill. A subfolder inherits from its parent unless you break that chain. When you drag a folder from one share into another, or restore it from a backup, that inheritance link can snap.
The result is a folder sitting inside a perfectly accessible share that nobody can open, because it kept the permissions from its old home.
The fix is to select the parent folder, apply the correct permission, and then check the box that propagates or replaces permissions on all child items. On Synology this is the "Apply to this folder, sub-folders and files" option. It rewrites everything underneath in one pass.
Do this on a copy first if you can
Propagating permissions is a bulk action. If you aim it at the wrong parent, you can flatten access across thousands of files in a second. On a big share, I test the propagation on a small subfolder before I let it loose on the whole thing.
Mistake 6: Forgetting the admin account is not automatically God
People assume the admin account can see everything. It cannot, not always. If an explicit Deny or a restrictive ACL exists on a folder, even admin gets bounced, and then folks panic thinking the data is corrupt.
Admin can always take ownership and reset permissions, but it does not silently bypass a No Access rule the way the root user does on a bare Linux box. Knowing this saves you from assuming the worst when admin gets denied. It is a permission problem, not a dead drive.
If you are ever fully locked out, most vendors have a documented recovery path. Synology, for example, publishes steps to reset the admin account and its permissions using the physical reset button, which is worth bookmarking before you ever need it.
A calm order of operations when you are locked out
When access breaks, resist the urge to click randomly. Work through it in a fixed order and you will find the culprit fast.
- Confirm whether it is one user or everyone. One user points at an individual Deny or group problem. Everyone points at the share layer or guest access.
- Check the shared folder permission first, then the ACL inside it. Both must allow.
- Scan the No Access column for the affected account specifically.
- Verify the account is actually in the group you think it is.
- If a folder was moved or restored, re-apply and propagate from the parent.
Nine times out of ten, one of those five steps is the answer. If you want a deeper primer on how these access controls are structured, the Wikipedia overview of access-control lists lays out the Allow, Deny, and inheritance logic that every NAS borrows from.
Back to my friend's photo folder
His three mistakes, in case you are curious: he had left an old explicit Deny on his wife's account from a test, he had disabled guest access without realising their smart TV used it, and he had edited the Unix boxes on a share that was actually running Windows ACL. Classic combo.
We cleared the Deny, made a Read Only "media" account for the TV, and edited the ACL grid instead of the mode boxes. Total time, about twelve minutes, most of which was me explaining why Deny beats Allow.
The lesson he took away is the same one I will leave you with. Permission problems feel scary because they look like data loss, but they are just rules stacked in the wrong order. Change one thing, test it, then change the next. Slow and boring beats fast and locked out every single time.
Frequently asked questions
Why can I see a NAS folder but not open it?
You almost certainly have permission at the shared folder layer but a Deny or No Access rule at the file ACL layer inside it. Both layers have to allow you. Check the folder's Permission tab in File Station, not just the shared folder settings.
Does Deny really override Allow on a NAS?
Yes, on every mainstream NAS an explicit Deny beats an Allow, even one granted through a group. If a user is in an allowed group but still blocked, look for an individual No Access entry tied to their account and clear it.
Should I keep the guest account enabled on my NAS?
For security, disable it if you can. But some smart TVs and media players rely on guest access, so before you turn it off, create a dedicated low-privilege account with Read Only access on the shares those devices need and enter those credentials on the device.
Why do my permission changes have no effect?
You are probably editing the wrong permission model. A share running Windows ACL ignores the simple owner/group boxes, and a share in Unix mode ignores the ACL grid. Check whether Windows ACL is enabled in the shared folder's advanced settings first.
How do I fix a folder that nobody can access after I moved it?
Moving or restoring a folder often breaks permission inheritance, so it keeps rules from its old location. Select the parent folder, set the correct permission, and enable the option to apply to sub-folders and files so it propagates downward.
Can the admin account always access every folder?
No. An explicit Deny or restrictive ACL can block even the admin account. Admin can take ownership and reset permissions, but it does not silently bypass a No Access rule, so a denied admin usually means a permission issue, not a failed drive.
