NAS permissions: set access correctly and diagnose denied files

Steps to follow

1. Identify the account and access path

   Write down the NAS model and software version, the client operating system, the share path and the exact error. Determine whether the failure occurs in SMB, a browser file manager, a sync application or a container. Those routes can use different identities. A file visible to an administrator in the web interface may still be unavailable to a normal SMB user.

   Check saved credentials on the client before changing server rules. A computer can reconnect using an older account even after you type a different username elsewhere. Close files safely, disconnect the relevant session and reconnect using the intended identity. Keep this test limited to the affected server; removing every stored credential creates unnecessary disruption and makes the original cause harder to trace.

2. Describe the intended rights before editing them

   Create a small access table naming the folder, user or group, and required actions. Reading a document, creating one, renaming it, deleting it and changing its permissions are different capabilities. A family archive might allow everyone to read while only designated editors can modify it. A backup application may need rights on its own destination without access to private household folders.

   Use groups for recurring roles where the NAS supports them. This makes onboarding and removal easier to understand than dozens of unrelated user exceptions. Avoid putting ordinary file users in an administrator group as a shortcut. Record the existing rules first, including inheritance, so you can undo a narrow change if the test produces an unintended result.

3. Inspect the relevant permission layers

   On Synology DSM, inspect the shared folder's Permissions settings and the file or subfolder ACL where appropriate. Group membership can introduce a No access rule that overrides a seemingly generous individual assignment. Advanced share permissions can add another requirement, so a permission preview is not always the entire effective-access picture. Use the documentation for the installed DSM version and folder type.

   On TrueNAS, distinguish the SMB share ACL from the dataset's filesystem ACL. Changing one does not automatically rewrite the other. Other NAS systems have their own rules and editors, so do not transplant a command designed for Synology into a QNAP or UGREEN shell. Identify the actual layer refusing access before choosing which setting to change.

4. Test with an ordinary account and a disposable file

   Create a test folder with harmless sample files and apply the smallest rule change needed. Reconnect the client, open a file, create another, rename it and attempt only the actions included in your access plan. Then test an account that should not have access. A successful owner login does not demonstrate that other users are correctly restricted.

   Check both existing and newly created files. Inheritance can make a new file behave differently from older content with explicit rules. If the result is correct, extend the change only to the intended scope. Save a short record of the rule, affected path and tests. Keep a verified backup or suitable recovery point before any broad permission migration.

Detailed guidance

Inheritance explains many inconsistent subfolders

An ACL is a set of access rules, and some rules can flow from a parent directory to its children. A child can also have explicit entries or a different inheritance state. That is why the top-level share may open while one subfolder fails. Inspect the failing object directly instead of repeatedly changing the parent and hoping every descendant will follow.

Do not apply a recursive reset merely to make the permission screen look uniform. Application folders, private homes and imported directories may have deliberate exceptions. Work on a copy or small branch first, note which entries are inherited, and verify the intended result before touching a larger tree. A folder full of readable files can still have incorrect delete or ownership rights.

Sync applications and containers have separate identities

A sync client can authenticate as one user while a container accesses the same path through a numeric user or group identity. A container's internal path can also map to a different host folder than expected. Record both sides of that mapping and consult the application's supported permission requirements. Do not grant broad privileges simply because the application reports permission denied.

For example, a media service may need read access to a library and write access only to its own configuration folder. Giving it write access to every personal document is unnecessary. Test the service's actual workflow after the change, including whether it can save its configuration and whether it can modify content that should remain read-only.

Permissions are not a backup or a complete ransomware defence

Restricting access reduces the scope of mistakes, but an authorised account can still delete or overwrite files within its rights. Keep versioned backups and recovery copies that ordinary working accounts cannot casually change. A snapshot on the same NAS can be useful for a quick rollback, while an independent copy addresses loss of the storage system itself.

Include access verification in a restore test. Recover a sample file to a separate folder, inspect its ownership and open it through the normal client account. A backup that restores the bytes but leaves the intended user unable to read them is an incomplete operational recovery. Document any permission adjustments required by the chosen backup tool rather than discovering them during an outage.

Compare the options

Frequently asked questions

Related guides

• Back Up Windows 11 to a NAS: Permissions, Versions and Recovery
• Google Drive Not Downloading Files: Permissions, Browser and Large Folders
• Set Up Immich on TrueNAS: Datasets, Permissions and First Upload
• Set up Syncthing on TrueNAS with the right datasets and permissions