There is a special kind of annoyance that comes from a share you can clearly see but cannot open. The folder sits right there in your file browser, taunting you, and the moment you double-click it Windows throws back "You do not have permission to access this folder" or macOS mutters something about the operation not being permitted.
The drive is fine. The network is fine. The problem is that two systems disagree about who you are and what you are allowed to touch.
The first time I hit this on a Synology DS220+, I spent twenty minutes convinced a cable was loose before I realised I had simply forgotten to add my own account to the folder. So let me save you that twenty minutes.
Understand the two layers of permission first
Almost every NAS stacks two separate gatekeepers, and you have to satisfy both. Miss either one and you get denied.
The first layer is the share permission, which controls who can connect to the shared folder over the network at all. The second is the folder (or NTFS-style) permission, which controls what you can do once you are inside.
Think of it like an apartment building. The share permission is the key to the front door of the building. The folder permission is the key to your actual apartment. Having one without the other gets you nowhere useful.
Step 1: Confirm which account you are actually using
Before touching a single permission, find out who your computer thinks you are. This is the single most common cause of a denied share, and it is invisible unless you go looking.
On Windows, your PC may be silently reusing an old saved credential. Open Command Prompt and run net use to list active connections, then run cmdkey /list to see stored credentials. If you see an old username pointed at your NAS, that is your culprit.
Clear the stale entry with cmdkey /delete:your-nas-name, then disconnect any mapped drive and reconnect. Windows will finally ask you for a fresh login.
- Run net use and note any connection to your NAS.
- Run net use * /delete to drop all current sessions.
- Reconnect to the share and type the username and password on purpose.
On a Mac, open Finder, press Command+K, and reconnect using the NAS address. If it grabs the wrong account, open Keychain Access, search for your NAS name, and delete the saved network password entry before trying again.
Step 2: Fix share permissions on Synology DSM
Log into DSM and open Control Panel > Shared Folder. Select the share that is giving you grief, click Edit, and move to the Permissions tab.
Here you will see every user account and its access level for this share. Find your account. If it shows "No access" or the checkbox is empty, that is your answer right there.
Set your user to Read/Write, click Save, and try the share again. Nine times out of ten on a home setup, this single toggle fixes everything.
Step 3: Check the advanced folder permissions
Passing the share check but still denied? The block is one level deeper, in the folder access control list.
Back in the Shared Folder editor, open the Advanced permissions or Permissions detail and look for an ACL. On DSM you can also right-click the folder inside File Station and choose Properties > Permission. This is where a subfolder can quietly carry its own rules that ignore the parent.
Add your user explicitly with Read and Write ticked. If you see a deny rule sitting above your allow rule, remove the deny, because on nearly every NAS a deny always beats an allow no matter the order.
For a deeper primer on how these access control lists actually work, the Wikipedia entry on access-control lists lays out the allow/deny logic cleanly.
Step 4: Do the same on QNAP QTS
QNAP calls the same concepts by slightly different names, which is half the confusion. Open Control Panel > Privilege > Shared Folders.
Find your share, click the Edit Shared Folder Permission icon (the little person with a pencil), and set the permission type to By user. Grant your account RW and apply.
Then check the folder-level layer. Go to Control Panel > Privilege > Shared Folders > Advanced Permissions and, if it is switched on, confirm your user has explicit access on the actual subfolder you are trying to open.
| Task | Synology DSM | QNAP QTS |
|---|---|---|
| User accounts | Control Panel > User & Group | Control Panel > Privilege > Users |
| Share permissions | Shared Folder > Edit > Permissions | Shared Folders > Edit Permission |
| Folder ACL | File Station > Properties > Permission | Advanced Permissions |
| Reset a password | User & Group > Edit | Users > Edit account |
Step 5: Rule out the sneaky causes
If all the permissions look correct and you are still blocked, a handful of quieter problems remain. I keep this shortlist taped to my mental wall.
- The account is disabled or expired. Check that the user itself is enabled, not just permitted on the share.
- SMB signing or version mismatch. An older device may need SMB1 while your NAS only offers SMB2/3. Raise the minimum protocol carefully, since SMB1 is a security risk.
- The share was recreated. Deleting and remaking a folder with the same name generates a brand new underlying ID, and old permissions do not carry over.
- A full recycle bin or quota. A user over quota can get write errors that read like permission failures.
Step 6: Force the clients to forget and reconnect
Permissions can be perfect on the NAS while your computer clings to a cached refusal. After every change above, give the client a clean slate.
On Windows, run net use * /delete again, then sign out and back in, or reboot if you are impatient. On macOS, eject the share from Finder, then remount it fresh with Command+K.
Roughly one in four "it is still broken" messages I get turn out to be a stale client session, not the NAS at all. Reconnecting costs you thirty seconds and rules it out for good.
When it is worth checking the logs
If you have been through every step and the door still will not budge, the NAS itself can tell you exactly what it rejected and why.
On DSM open Log Center and filter for connection or file transfer events. On QTS check System Logs. You are looking for a line that names your username and the folder, which usually points straight at the offending rule.
Nine times out of ten the fix ends up being small: one missing user on one folder, or one machine holding onto a login from three months ago. Work the two layers in order, clear the client cache, and the share opens like it should. Now go reconnect that mapped drive with the account you actually meant to use.
Frequently asked questions
Why can I see the NAS share but not open it?
Seeing the share means you passed browse-level visibility, but opening it requires both share permission and folder permission. You are almost certainly missing one of those two grants for your specific user account. Check the Permissions tab on the share and then the folder ACL underneath it.
I have admin rights on the NAS, so why am I still denied?
Being an administrator of the NAS interface does not automatically give your user Read/Write on every shared folder, especially if a folder has its own ACL. An explicit deny rule on that folder will also override your admin status. Add your account directly to the folder permissions with Read/Write.
Does clearing saved Windows credentials really help?
Yes, very often. Windows caches the first username and password you use for a NAS and silently reuses it, even after you change your account. Run cmdkey /list to see stored entries, delete the stale one, then reconnect and type the correct login on purpose.
What is the difference between share permissions and folder permissions?
Share permissions decide whether you can connect to the shared folder over the network at all. Folder permissions decide what you can do once inside, like read, write, or delete. A NAS checks both and gives you whichever is more restrictive.
Could an SMB version mismatch cause a permission error?
It can, because an old device that only speaks SMB1 may fail to authenticate against a NAS set to a higher minimum protocol, and the failure can look like a permission denial. Raise the minimum SMB version cautiously, since SMB1 has known security problems. Prefer updating the client device instead.
