How to Structure Shared Folders on a Synology NAS

How to structure Shared Folders on a Synology NAS for clean permissions, policies, backups, and SMB access.

When setting up a Synology NAS, an important design decision is how to structure the data exposed to users and devices.

For example:

  • should all generally accessible data live below a single shared folder?

    Public
    ├── Books
    ├── Music
    ├── Videos
    ├── Documents
    └── Software
    
  • Or should the individual categories become Synology Shared Folders themselves?

    Books
    Music
    Videos
    Documents
    Software
    

For most installations, the second approach is preferable: use separate Shared Folders for logically distinct data sets and ordinary directories for their internal organization.

Shared Folders are administrative boundaries

A Synology Shared Folder is more than simply a directory appearing as an SMB share. DSM uses Shared Folders as important administrative and security boundaries.

Permissions can be assigned directly to a Shared Folder, preferably through user groups. For example:

Shared FolderFamilyMedia PlayersAdminBackup
BooksRead/WriteReadRead/WriteRead
MusicRead/WriteReadRead/WriteRead
VideosRead/WriteReadRead/WriteRead
DocumentsRead/WriteNo AccessRead/WriteRead
SoftwareReadNo AccessRead/WriteRead

This is considerably easier to understand and maintain than putting everything underneath Public and building a complex hierarchy of ACLs within it.

DSM can assign permissions to individual directories and files, including inherited permissions. However, the deeper and more exceptional the ACL structure becomes, the harder it is to determine the effective permissions of a particular user.

A simpler model is therefore preferable:

ADVICE: Use Shared Folders for security and administrative boundaries. Use directories for organization.

Shared Folders also define policy boundaries

Permissions aren’t the only reason to separate data.

Various Synology features and policies operate at the Shared Folder level. This allows different types of data to be handled differently.

For example:

Music
  Recycle Bin: enabled
  Snapshots: 7 days

Videos
  Recycle Bin: disabled
  Snapshots: disabled

Documents
  Recycle Bin: enabled
  Snapshots: 90 days
  Backup: daily
  Permissions: restricted

This can become particularly relevant for Btrfs snapshots, backups, quotas, encryption, recycle bins, and application-specific access.

There is therefore little benefit in avoiding a reasonable number of Shared Folders merely to keep the list short.

Don’t go too far in the other direction

That doesn’t mean every directory should become a Shared Folder.

For example, this is a reasonable structure:

Videos
├── Movies
│   ├── Action
│   ├── Comedy
│   └── Science Fiction
├── TV Shows
├── Documentaries
└── Home Videos

Here, Videos is the Shared Folder while everything below it consists of normal directories.

Creating separate shares for Movies, TV Shows, Documentaries, and Home Videos would usually provide little benefit if they all have the same permissions and policies.

They should become separate Shared Folders only when there is a reason to treat them differently—for example, different permissions, backup strategies, quotas, encryption, snapshots, or application requirements.

Avoid a generic Public share

Another reason not to put everything underneath Public is the ambiguity of the name.

What exactly does public mean?

  • Available to every authenticated NAS user?
  • Available anonymously?
  • Available to every device on the LAN?
  • Readable by everyone but writable only by selected users?

A better approach is to let the Shared Folder name describe “what the data is”, while permissions describe “who may access it”.

For example:

Books
Documents
Music
Photos
Scans
Software
Videos

Permissions can then be assigned using groups such as:

nas-users
family
media-readers
media-editors
backup-users

Whenever possible, permissions should be assigned to groups rather than individual user accounts. This makes the configuration considerably easier to maintain as users and devices change.

Cleaner SMB paths

Separate Shared Folders also result in straightforward SMB paths:

\\nas\Books
\\nas\Music
\\nas\Videos

instead of:

\\nas\Public\Books
\\nas\Public\Music
\\nas\Public\Videos

This also makes it immediately obvious which directories represent NAS shares and which are merely directories within a share.

For a typical home or homelab Synology NAS, therefore start with something similar to:

Synology NAS
│
├── Books           [Shared Folder]
├── Documents       [Shared Folder]
├── Music           [Shared Folder]
├── Photos          [Shared Folder]
├── Scans           [Shared Folder]
├── Software        [Shared Folder]
├── Videos          [Shared Folder]
└── Backup          [Shared Folder]

Then organize the contents using ordinary directories:

Videos
├── Movies
├── TV Shows
├── Documentaries
└── Home Videos

Music
├── Classical
├── Jazz
└── Rock

Books
├── E-Books
├── Manuals
└── Magazines

The important distinction is not whether two sets of files belong to different categories. The question is whether they need an “independent administrative policy”.

If the answer is yes, create separate Shared Folders. If the distinction is merely organizational, use directories.

That keeps the Synology configuration simple while leaving enough flexibility to introduce different permissions, snapshots, backup policies, quotas, or other policies later.