Skip to main content

FileSystem Permissions Format Reference

  • "What does LRWDMA mean in FSAA?"
  • "What does the 'A' permission stand for in Netwrix Access Analyzer?"
  • "Why are there letters like L, R, W in permission strings?"

Overview​

The Netwrix Access Analyzer (formerly Enterprise Auditor) for FSAA (FileSystem Access Auditing) permission views include columns called AllowRightsDescription and DenyRightsDescription, which use a compact letter-based format to represent access rights to files and folders. This article explains what each letter means, how to read the permission strings, and where these codes are used.

Instructions​

Permission Letter Definitions​

Each letter in the permission string corresponds to a specific type of access:

LetterNameBit ValueDescription
LList32 (0x20)List folder contents or traverse folder paths
RRead1 (0x01)Read data from files or list contents of a folder
WWrite2 (0x02)Write data to files or create files and folders
DDelete4 (0x04)Delete files and folders
MManage8 (0x08)Modify permissions or change ownership
AAdmin16 (0x10)Full administrative control, including ownership rights

NOTE: Permission strings are formed by combining the letters in the order L-R-W-D-M-A. An empty string means no permissions are granted.

Example Permission Strings​

StringMeaning
LRWDMAFull Control
LRWDModify (no admin rights)
LRWStandard user access
LRRead-only access
LTraverse only
RWRead and write without list
AAdmin-only
(empty)No permissions

Views That Use This Format​

The letter-based permission format is used in the following database views:

  • SA_FSAA_ExpandedPermissionsView — Includes both direct and inherited effective permissions.
  • SA_FSAA_DirectPermissionsView — Directly assigned permissions only.
  • SA_FSAA_InheritedPermissionsView — Permissions inherited from parent folders.
  • SA_FSAA_PermissionsView — Combined view of direct and inherited permissions.
  • SA_FSAA_EffectiveAccessView — Effective permissions on shared resources.

In addition to AllowRightsDescription and DenyRightsDescription, the permission views also include:

  • Boolean columns: AllowList, AllowRead, AllowWrite, etc.
  • Raw bitmask columns: AllowRights, DenyRights
  • Windows-style descriptions: AllowMaskDescription, DenyMaskDescription

Technical Details​

The permission strings are generated using SQL bitwise logic. For example:

(CASE WHEN (p.AllowRights & 32) <> 0 THEN 'L' ELSE '' END) +
(CASE WHEN (p.AllowRights & 1) <> 0 THEN 'R' ELSE '' END) +
(CASE WHEN (p.AllowRights & 2) <> 0 THEN 'W' ELSE '' END) +
(CASE WHEN (p.AllowRights & 4) <> 0 THEN 'D' ELSE '' END) +
(CASE WHEN (p.AllowRights & 8) <> 0 THEN 'M' ELSE '' END) +
(CASE WHEN (p.AllowRights & 16) <> 0 THEN 'A' ELSE '' END) AS AllowRightsDescription

Important Usage Notes​

  • Deny overrides allow: If both Allow and Deny include the same letter, the permission is denied.
  • Empty string means no rights: No access is granted if the string is blank.
  • Always in order: Letters appear in the standard order (L-R-W-D-M-A) when present.
  • Effective access: Use the expanded view to see the final calculated result after inheritance is resolved.