Traditional file shares may display folders even when a user does not have permission to open them. The user sees a long list of department, project, and administrative folders, then receives an access-denied message when they click the wrong one.
Access-Based Enumeration, commonly called ABE, changes that experience. On an SMB share, it hides files and folders the current user is not authorized to access.
What ABE Changes: ABE is primarily a visibility feature. It works with the underlying permissions; it does not replace them.
- Without ABE:
- Users may see folder names they cannot open
- Share navigation becomes cluttered
- Sensitive project names may be exposed
- Help-desk tickets increase when users encounter access-denied errors
- With ABE:
- Users see only the folders their permissions allow them to access
- Shared departmental roots are easier to navigate
- Unauthorized folder names are less visible
This is useful for shared roots containing many business units, customer folders, legal matters, or projects.
ABE Is Not An Access-Control Boundary: The actual security controls remain the share and file system permissions. If permissions accidentally grant access, ABE will not protect the data.
Likewise, disabling ABE does not grant access. It only makes unauthorized items visible in directory listings; the permission check still occurs when the user tries to open them.
Think of the relationship this way:
- Permissions decide whether the user may access the object.
- ABE decides whether an unauthorized object appears in the listing.
Always fix permissions first.
Planning The Permission Model: ABE works best with a clean group-based permission structure. A common model is:
- Create identity-provider groups for each access level.
- Assign permissions to groups rather than individuals.
- Use separate read and modify groups where required.
- Keep inherited permissions predictable.
- Enable ABE after access has been tested.
Avoid deep trees filled with one-off permission exceptions. ABE may hide the visual complexity from users, but administrators still have to troubleshoot it.
Testing ABE: Test with multiple accounts:
- A user with no access
- A user with read access
- A user with modify access
- An administrator
For each account, verify both visibility and actual access. Confirm that:
- Unauthorized folders are hidden
- Authorized folders are visible
- Direct paths do not bypass permissions
- File creation and modification work as expected
- Nested folders inherit the intended access
Refresh user sessions after group changes. Authentication tokens and cached directory information can delay the visible effect of updated membership.
Performance And User Expectations: ABE requires the file service to evaluate permissions while building directory listings. In most designs, this is an acceptable trade-off, but large directories and complex access control lists warrant testing.
Also communicate the change to users. A folder that disappears because access was removed can look like lost data. The help desk should know that visibility reflects current authorization.
Where ABE Helps: Good candidates include:
- Departmental shared roots
- Home-directory structures
- Customer or case folders
- Project repositories
- Education and public-sector shares
Shares intended for broad discovery may not need ABE. The feature should align with the namespace’s purpose.
Summary: Access-Based Enumeration makes Nutanix Files easier to navigate and reduces unnecessary exposure of folder names. It does not create security permissions; it reflects the permissions already in place.
Build a clean, group-based access model, test with representative users, and treat ABE as the presentation layer atop a well-designed authorization system.
Official Resources
What Do You Think? Would ABE simplify your largest departmental shares, or do users need to see folders before requesting access?