Lets say you have WORKERS who need read/write access to some shared folders, read only to others. For a few shared folders, you want to delegate special WORKERS as TEAMLEADS to create content that is only read by the other non-teamlead WORKERS. You also have some contractors who need the same access to almost everything WORKERS need except one employee only shared folder.

Let’s say JOE is your teamleader, Sally a worker, and Dave a contractor.

In Windows, you put JOE into the WORKERS and TEAMLEADS groups, Sally into the WORKER group and DAVE in the WORKER and CONTRACTOR groups.

For shared folder ACLs, Windows gives you the option to independently “GRANT” and “DENY” permission for “FULL CONTROL, CHANGE or READ”

For the employee only shared folder where TEAMLEADS are the content generators, you give TEAMLEADS FULL CONTROL, WORKERS get READ and you set CONTACTORS with DENY FULL CONTROL, CHANGE and READ.

For shared folders where everyone has read/write but no permission to change rights, you give WORKERS CHANGE and READ.

In the TeraStation using the same group membership, JOE can’t do his job because JOE is limited to the most restrictive access. Since WORKERS only have READ access, JOE can’t read and write even if you put TEAMLEADS in for READ/WRITE access. SALLY is fine, but there is no DENY model so you can’t block read access for CONTRACTORS.

The work around results in way more groups or (worse) you skip groups and manage permissions for each person individually. Its like wrtng sntcs wtht vwls. If you’re a Windows shop you may have to completely redesign your entire organization’s group structure in order to implement the kind of share permissions control you do today with your Windows Server.