How do POSIX ACLs work in Data Lake Gen2?

Gen2 supports POSIX-style ACLs with access ACLs (control permissions for a specific file or directory) and default ACLs (inherited by new child items in a directory). Each ACL entry specifies a principal (user, group, or other), and permissions are read (r), write (w), and execute (x). The execute permission on directories allows listing contents. ACLs are evaluated in order: owning user, named users, owning group or named groups, other. Unlike Blob Storage RBAC, ACLs provide file-level and directory-level granularity, which is essential for multi-team data lake architectures.

Should I use RBAC or ACLs for Gen2 access control?

Use both, but for different purposes. Azure RBAC roles (Storage Blob Data Owner, Contributor, Reader) are evaluated first and grant broad access at the storage account or container level — ideal for service principals and administrators. POSIX ACLs provide fine-grained control at the directory and file level — ideal for restricting data scientists to specific folders. A common pattern is to assign Storage Blob Data Contributor to ETL pipelines (they need broad write access) and use ACLs to give analytics users read-only access to specific datasets within the lake.

Data Lake Gen2 Config Builder

StorageAzure

Build ADLS Gen2 filesystem configurations with POSIX ACLs and lifecycle policies.

ADLS Gen2 Configuration

Build ADLS Gen2 filesystem, ACL, and lifecycle management configurations.

Required Fields

storageAccountNameresourceGroupisHnsEnabledfilesystemsfilesystems[0].name

{
  "storageAccountName": "stadatalakeprod",
  "resourceGroup": "rg-data",
  "location": "eastus2",
  "sku": "Standard_ZRS",
  "isHnsEnabled": true,
  "allowSharedKeyAccess": false,
  "minimumTlsVersion": "TLS1_2",
  "publicNetworkAccess": "Disabled",
  "networkRules": {
    "defaultAction": "Deny",
    "bypass": "AzureServices",
    "virtualNetworkRules": [
      {
        "subnetId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-networking/providers/Microsoft.Network/virtualNetworks/vnet-data/subnets/snet-analytics"
      }
    ],
    "privateEndpoints": [
      {
        "name": "pe-datalake-dfs",
        "groupId": "dfs",
        "subnetId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-networking/providers/Microsoft.Network/virtualNetworks/vnet-data/subnets/snet-pe"
      }
    ]
  },
  "filesystems": [
    {
      "name": "raw",
      "defaultEncryptionScope": "$account-encryption-key",
      "directories": ["ingestion/events", "ingestion/logs", "staging"]
    },
    {
      "name": "curated",
      "directories": ["dimensions", "facts", "aggregations"]
    },
    {
      "name": "sandbox",
      "directories": ["exploration", "notebooks"]
    }
  ],
  "accessControl": [
    {
      "filesystem": "raw",
      "path": "/",
      "acl": [
        { "type": "user", "id": "00000000-0000-0000-0000-000000000000", "permissions": "rwx", "scope": "access" },
        { "type": "group", "id": "11111111-1111-1111-1111-111111111111", "permissions": "r-x", "scope": "access" },
        { "type": "other", "permissions": "---", "scope": "access" },
        { "type": "group", "id": "11111111-1111-1111-1111-111111111111", "permissions": "r-x", "scope": "default" }
      ]
    },
    {
      "filesystem": "curated",
      "path": "/",
      "acl": [
        { "type": "user", "id": "00000000-0000-0000-0000-000000000000", "permissions": "rwx", "scope": "access" },
        { "type": "group", "id": "22222222-2222-2222-2222-222222222222", "permissions": "r-x", "scope": "access" },
        { "type": "other", "permissions": "---", "scope": "access" }
      ]
    }
  ],
  "lifecycleManagement": {
    "rules": [
      {
        "name": "archive-old-raw",
        "type": "Lifecycle",
        "definition": {
          "filters": {
            "blobTypes": ["blockBlob"],
            "prefixMatch": ["raw/ingestion/"]
          },
          "actions": {
            "baseBlob": {
              "tierToCool": { "daysAfterModificationGreaterThan": 30 },
              "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
              "delete": { "daysAfterModificationGreaterThan": 365 }
            }
          }
        }
      }
    ]
  }
}

Generated Output

Output will appear here...

About This Tool

Azure Data Lake Storage Gen2 combines the scalability of Azure Blob Storage with a hierarchical namespace optimized for big data analytics. Built on top of Azure Storage accounts, Gen2 adds POSIX-compliant access control lists (ACLs), directory-level operations, and integration with analytics services like Synapse, Databricks, and HDInsight. Configuration involves enabling the hierarchical namespace, defining filesystem containers, setting POSIX ACLs for fine-grained access, and creating lifecycle management policies for tiering data to cool or archive tiers. The Config Builder helps you define these settings correctly.

When to Use This Tool

•Configuring ADLS Gen2 filesystems with POSIX ACL hierarchies that mirror organizational data access patterns
•Building lifecycle policies that automatically move data from hot to cool to archive based on last access time
•Setting up Gen2 storage accounts with the correct redundancy (LRS, ZRS, GRS) and network security configurations

Frequently Asked Questions

How do POSIX ACLs work in Data Lake Gen2?: Gen2 supports POSIX-style ACLs with access ACLs (control permissions for a specific file or directory) and default ACLs (inherited by new child items in a directory). Each ACL entry specifies a principal (user, group, or other), and permissions are read (r), write (w), and execute (x). The execute permission on directories allows listing contents. ACLs are evaluated in order: owning user, named users, owning group or named groups, other. Unlike Blob Storage RBAC, ACLs provide file-level and directory-level granularity, which is essential for multi-team data lake architectures.
Should I use RBAC or ACLs for Gen2 access control?: Use both, but for different purposes. Azure RBAC roles (Storage Blob Data Owner, Contributor, Reader) are evaluated first and grant broad access at the storage account or container level — ideal for service principals and administrators. POSIX ACLs provide fine-grained control at the directory and file level — ideal for restricting data scientists to specific folders. A common pattern is to assign Storage Blob Data Contributor to ETL pipelines (they need broad write access) and use ACLs to give analytics users read-only access to specific datasets within the lake.

Related Learning Guides

Storage Account Types22 min read

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.