Permissions are the least glamorous part of a Synology Drive setup and the part that decides whether it is safe. Most offices set them once, badly, on day one. Here is the pattern that stays manageable as the team grows and changes.
Drive follows the rule of the underlying system: a Team Folder is a DSM shared folder, and who can use it is decided by user and group permissions on that folder. Get this layer right and Drive feels effortless — everyone sees exactly their work and nothing else. Get it wrong and the symptoms are familiar: staff browsing folders that were never theirs, an ex-employee's account still active, and a public link quietly bypassing the whole design.
Create DSM groups that mirror the business — Accounts Team, Design Team, Managers — and grant Team Folder permissions to the groups. People join and leave groups; folders never need editing when staff change. The alternative — permissions typed person by person onto every folder — rots within months: the folder list becomes a museum of ex-employees and exceptions nobody dares to clean. With groups, a new joiner's access is one membership tick, and a leaver's removal is the same tick in reverse.
Most permission setups know only two states: full access or nothing. The useful middle is read-only: reference material — final quotations, issued drawings, price lists, policy documents — should be readable by everyone who needs it and editable by almost nobody. Read-only groups stop the quiet disaster of someone 'tidying' the master copy. If a folder's contents are meant to be consumed rather than produced, its default should be read-only with a small named set of editors.
Drive's sharing links are convenient, and they are also a side door: a public link lets anyone holding it reach a file without ever passing your folder permissions. In Drive Admin Console, decide link policy per folder — who may create links, whether public links are allowed at all, and require password protection and an expiry date where they are. For genuinely sensitive folders (accounts, HR, salaries), disable public link sharing outright. Then, once a quarter, review the links currently alive in the Admin Console; links created 'just for today' have a way of living for years.
Permissions fail socially more often than technically. The routine that keeps you safe is boring and absolute:
The Admin Console's logs show connections and file activity per user — one more thing that only works when every human has their own account.
Drive permissions work at the Team Folder level. When you catch yourself wanting 'this subfolder visible to them, that one not', the honest answer is that you actually have two folders wearing one name. Split them into two Team Folders with clean permissions each. It looks like more structure; in practice it is less — every exception you bolt onto subfolders is a future afternoon spent explaining why someone saw something they should not have.
The setup video shows users, folders and client access being configured live — the foundation this permissions pattern is built on.
▶️ Watch Full VideoYes. Users without any permission on a Team Folder simply do not see it in Drive — not greyed out, not locked, just absent. No-access is the cleanest setting there is, and the right default for folders outside someone's job.
Yes, and it is an afternoon's work, not a project: create the groups, grant the groups the same access people have today, verify, then remove the individual grants. From that day on, every staff change is a one-tick job instead of a folder-by-folder expedition.
Normal users generally cannot audit permissions — that is an admin view. What users can do is create sharing links within the limits the admin set, which is why link policy belongs in the permission design and not as an afterthought.