How to Organize Shared Folders and Access Rights on a File Server

The short answer

Order on a file server rests on four rules:

1. A shallow structure by department with clear owners.
2. Permissions only through groups, never to individual users.
3. Least privilege: read-only by default, write access only where it is needed.
4. Snapshots and versions, so a mistake or ransomware does not mean lost work.

These rules work the same on Windows Server, a Synology or QNAP NAS, or Samba on Linux — only the interface differs.

Folder structure

Keep it simple and no more than two or three levels where permissions change:

Shares/
├── Common/          everyone: read, staff: write in subfolders
├── Departments/
│   ├── Finance/     Finance: modify, Management: read
│   ├── Sales/       Sales: modify
│   ├── HR/          HR: modify, nobody else
│   └── Marketing/   Marketing: modify
├── Projects/
│   └── <project>/   project team: modify
└── Archive/         everyone with access: read only

Principles:

• Permissions are set at the top levels. Deeper folders inherit them. If you need a special case at level five, the structure is wrong.
• Every top folder has an owner — a person who decides who gets access.
• No personal data in shared folders. Personal files belong in user home folders or the user's cloud storage.

Group-based permissions

Create groups by role and access level, for example:

• GG-Finance-RW — finance staff, read and write.
• GG-Finance-RO — management, read only.

Then grant permissions on the folder to the groups, not to people. When someone joins or leaves, you change group membership, not folder permissions. On Windows this is the logic behind the classic AGDLP model: users go into role groups, and role groups receive access to resources.

On Windows, a grant can be scripted like this:

icacls "D:\Shares\Departments\Finance" /grant "CORP\GG-Finance-RW:(OI)(CI)M"
icacls "D:\Shares\Departments\Finance" /grant "CORP\GG-Finance-RO:(OI)(CI)RX"

(OI)(CI) makes the permission apply to subfolders and files, M is modify, RX is read and execute.

Least privilege in practice

• Read-only by default. Write access is given when a task requires it.
• No "Full control" for users. Modify is enough to work; full control lets people change permissions themselves.
• Avoid "Everyone". Use an authenticated users group or specific groups instead.
• Hide what is not available. Access-based enumeration on Windows (and similar options on NAS) shows users only the folders they can open.
• Share permissions vs filesystem permissions. On Windows, a common approach is to set share permissions broadly for authenticated users and control access with NTFS permissions — one place to manage instead of two.

Versioning and snapshots

• Snapshots store the state of a volume at a point in time. On Windows, Volume Shadow Copies let users restore a file via Previous Versions. On a NAS, scheduled snapshots do the same, often with protection against deletion.
• Schedule them several times a day for active data and keep a reasonable history.
• Snapshots are not a backup. They live on the same storage. Keep a separate copy elsewhere.

How to stop permission chaos

If the server already looks like a maze:

1. Export current permissions and find folders with broken inheritance and direct user permissions.
2. Agree on the target structure and folder owners with department heads.
3. Create groups and fill them according to roles.
4. Move data into the new structure in stages, with permissions set only at the top levels.
5. Remove direct user permissions and restore inheritance below the top level.
6. Introduce a simple process: access requests go to the folder owner, and changes are made only through groups.
7. Review regularly — at least when people change roles or leave.