Configuring Advanced Permissions for Shared Drives on UNAS and ENAS

Advanced Permissions enables Windows ACL and subfolder permission control for shared drives. Use it to manage access at the shared drive, folder, or file level.

Before You Start

Enabling Advanced Permissions affects all shared drives in UniFi Drive.

• This change cannot be undone. You cannot return to the original Owner, Editor, and Viewer permission model.
• Existing shared drive roles are automatically converted to corresponding Windows ACL permissions.
• You can configure permissions for individual files and subfolders after migration is complete.
• NFS and USB drive share permissions are not affected.
• Ensure that all encrypted storage pools are unlocked. UniFi Drive cannot start the migration while a storage pool is locked.

Note: Deactivated shared drives are skipped during migration. Activate them before enabling Advanced Permissions if you want to migrate their permissions.

Enable Advanced Permissions

1. Go to UniFi Drive > Settings > Services.
2. Under File Services, enable Windows ACL and subfolder permission control for Shared Drives.
3. If prompted, unlock any encrypted storage pools.
4. Review the confirmation message and follow the on-screen instructions to start the migration.

What Happens During Migration

UniFi Drive automatically migrates permissions for each active shared drive.

• Shared drives are temporarily read-only. Files remain available to read, but uploading, moving, renaming, deleting, and changing permissions are unavailable.
• Active SMB connections may be paused or disconnected while a shared drive is being migrated.
• To minimize disruption, perform the migration during off-peak hours.
• To view progress, open Active Transfers in the top-right corner of UniFi Drive. The migration is shown as Updating Permissions....

If migration is interrupted, return to UniFi Drive > Settings > Services and click Resume Migration.

ENAS Storage Requirements

For data created before updating to UniFi Drive 5.0, migration requires additional metadata storage on ENAS. Each existing file, including empty files, may use approximately 11 KB of additional space.

Data created after updating to UniFi Drive 5.0 uses the newer dnodesize format, which reduces the additional metadata requirement to approximately 130 bytes per file.

Understand Permission Evaluation

UniFi Drive follows standard Windows NTFS permission evaluation rules. A person’s effective permissions combine all entries that apply to their account and any roles or groups they belong to.

Permissions are evaluated in this order:

1. Explicit Deny
2. Explicit Allow
3. Inherited Deny
4. Inherited Allow

Keep the following in mind:

• An explicit permission overrides an inherited permission.
• At the same level, Deny overrides Allow.
• A Deny entry assigned directly to a person or through any of their roles or groups removes that permission.
• Allow permissions are cumulative. For example, assigning Read permission to a subfolder does not reduce a person’s inherited Modify permission.
• UniFi Drive checks access to each parent folder before checking access to the target subfolder or file. A person needs Traverse/Execute permission for every parent folder in the path. An explicit Deny for Traverse/Execute on a parent folder prevents access to its subfolders, even if the person has permission to access them.
• To limit access to a parent folder while allowing access to a subfolder, do not apply an explicit Deny to the parent folder. Instead, grant only Traverse/Execute permission and set its scope to This folder only.

To reduce access to a folder or file, add an explicit deny entry or disable inheritance on that item and remove the unwanted permission entries.

When to Use Deny Permissions

By default, UniFi Drive uses Allow permissions. If a person is not granted permission, access is denied automatically.

Use Allow permissions for general access control. Use Deny permissions only to create specific exceptions for people who receive access through a role or group.

For example, the Marketing Team group has Modify permission for the shared Marketing folder. An intern joins the group and needs to view the folder for onboarding, but must not edit or delete files.

To create this exception:

1. Keep Modify permission for the Marketing Team group.
2. Add the intern to the folder’s permission list.
3. Add an explicit Deny entry for Write and Delete permissions for the intern.

The intern retains Read access through the group, but cannot edit or delete files because the explicit Deny entries override the group’s Allow permissions.

Note: Avoid applying Deny permissions to an entire role or group. A Deny entry can unintentionally prevent access for administrators or people who belong to multiple groups.

Preset Permission Types

Note: Moving a file to another shared drive creates a new inode. Any explicit permissions assigned to that file are removed. This matches standard Windows behavior.

Detailed Permissions

For more information, see Microsoft’s File and Folder Permissions and FileSystemRights documentation.

Common Permission Scenarios

Scenario 1: Provide Access to a Subfolder Without Access to Other Subfolders

You want a contractor to access only /Shared/Projects/Project-A without accessing other project folders.

1. On /Shared/Projects, grant Traverse Folder/Execute File and set the scope to This folder only.
2. On /Shared/Projects/Project-A, grant the contractor Read or Modify permission.
3. Make sure the contractor does not inherit List Folder/Read Data or other permissions for /Shared/Projects or its other subfolders.

The contractor can access Project-A through its direct path but cannot view the contents of /Shared/Projects or access other project folders.

Note: To let a person browse and select Project-A in UniFi Endpoint or Windows Explorer, you must grant List Folder/Read Data for /Shared/Projects. This also reveals the names of all subfolders at that level. If project names must remain hidden, use separate shared drives or separate parent folders.

Scenario 2: Allow Editing Without Allowing Deletion

You want team members to create, edit, and save documents in a shared folder without deleting files or subfolders.

1. On the target folder, assign the team a custom Allow permission set that includes the required Read and Write permissions.
2. Do not grant Delete or Delete Subfolders and Files permissions.
3. Ensure that the team does not inherit Modify, Delete, or Delete Subfolders and Files permissions from a parent folder. If necessary, disable inheritance on the target folder and remove the unwanted inherited entries.

Team members can create and edit files but cannot delete existing files or subfolders.

Note: Renaming or moving a file may require Delete permission. People without Delete permission may be unable to rename or move files.

Important Considerations

Backups to an ACL-Enabled Shared Drive

When using Rsync or Local Backup to back up files to an ACL-enabled shared drive, newly backed-up files initially grant permissions only to the file owner and SYSTEM.

The shared drive’s inherited permissions are applied only after the backup completes successfully. If the backup fails or is interrupted, inheritance is not applied automatically. Re-run the backup successfully or apply permissions manually.

Share Links

To create a share link, you need at least Read permission for the file or folder.

If the person who created a share link is deleted:

• Links created by an administrator remain active and transfer to the Console Owner.
• Links created by a standard user are deleted and no longer work.

Active Directory Accounts

If you enable SMB sign-in with Windows Active Directory accounts, you cannot directly configure Windows permissions for AD users or groups in UniFi Drive.

Use the corresponding local UniFi Drive users when configuring permissions. On the Drive web permission page, hover over a user or role to view its mapped Windows display name.

Special Users and Permission Entries

The Drive web interface may display Windows, Active Directory, Unix, or unresolved security identifier (SID) entries, including SYSTEM and everyone.

Unresolved SID entries usually represent deleted users. They appear in the format `uisys-xxxx`.

These entries cannot be changed in UniFi Drive and are shown as Read-only.

Mapped Windows Names

When you view or configure permissions in Windows, such as through File Explorer or SMB, UniFi Drive users and groups are represented by mapped Windows names, such as an internal ID or SID string like `uisys-xxxx`.

To find a user or role’s mapped Windows name, hover over it in the Drive web permission list. Use this name to identify or verify the corresponding permission entry in Windows.

UniFi Fabric and UniFi Endpoint Permissions

UniFi Fabric and UniFi Endpoint support permissions only at the top level of a shared drive. To configure permissions for subfolders or individual files, use the UniFi Drive web interface.

Resolve SMB Connection Issues After an Upgrade

If SMB connections fail when using the NAS hostname, or Windows repeatedly reports an invalid username or password, NTLM authentication may be disabled, and the new computer account may be missing its Service Principal Name (SPN).

1. In Active Directory Users and Computers, find and remove the old NAS computer account to prevent SPN conflicts.
2. Open Command Prompt as a Domain Admin.
3. Run the following command: setspn -S cifs/<Your-NAS-Name> <New-Computer-Account-Name>
   Example: setspn -S cifs/UNAS-Pro-8 UNAS-3066C4FAB0

UniFi Endpoint Shadow Users in Windows

UniFi Drive creates shadow users for UniFi Endpoint and maps permissions configured in the Drive web interface to these accounts.

When viewing ACL permissions in Windows, you may see accounts in the format User_Name (Endpoint). Do not change these permissions directly in Windows, as this may cause permission errors in SMB or UniFi Endpoint.