A path ACL is the permission list on a specific folder or file in Data Lake Storage Gen2. It says which users, groups, or application identities can read, write, or pass through that path. This is different from giving broad access to the whole storage account. Path ACLs let teams share one lake safely across projects, zones, or departments. They also require care, because a missing execute permission on a parent directory can block access even when the file itself looks readable.
Data Lake path ACL, ADLS Gen2 ACL, access ACL, directory ACL, file ACL, POSIX ACL
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-17
Microsoft Learn
In Azure Data Lake Storage Gen2, a path ACL is a POSIX-like access control list applied to a directory or file path. It works with Azure RBAC and ownership metadata to determine which users, groups, service principals, or managed identities can traverse, read, write, or execute data.
In Azure architecture, path ACLs live in the storage data plane for accounts that use the hierarchical namespace. Azure RBAC can grant broad account or container permissions, while ACLs refine access at directory and file paths. ACL entries include owner, owning group, named users or groups, mask, other, and optional default entries for child paths. They are evaluated with identity, ownership, and traversal permissions. Path ACLs appear in Data Lake APIs, Azure CLI, Storage Explorer, SDKs, recursive ACL jobs, and lakehouse access runbooks.
Why it matters
Path ACL matters because many data lakes contain mixed sensitivity, ownership, and lifecycle zones under one storage account. Without path-level controls, teams either overexpose data or create too many separate accounts and containers. A correct ACL design lets pipelines read raw data, analysts query curated folders, partners access approved extracts, and administrators retain control of restricted zones. Misconfigured ACLs cause broken jobs, failed notebooks, privacy incidents, and long investigations because access depends on both the target path and every parent directory. Clear ACL runbooks help teams prove who can access which data and why. This prevents emergency access widening during incidents. Design inheritance carefully before broad folder rollout.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In Storage Explorer or the Azure portal ACL pane, a Data Lake path shows owner, group, permissions, named entries, mask, and default ACL values. during reviews. screens.
Signal 02
In Azure CLI output from storage fs access commands, ACL strings reveal whether users, groups, service principals, and default entries have expected permissions. during audits. during change reviews.
Signal 03
In pipeline, notebook, or Synapse failures, authorization errors often point to a missing path ACL, parent execute permission, or stale identity object ID. during incidents. during incident triage.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Grant a managed identity read access to curated lake folders without exposing raw or restricted zones.
Apply default ACLs so new files and directories inherit project-specific access rules.
Troubleshoot authorization failures caused by missing parent execute permission or stale object IDs.
Run recursive ACL updates when an existing folder tree needs a new team, partner, or pipeline identity.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Genomics collaboration lake access
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
HelixBridge Research operated a shared Azure Data Lake Storage Gen2 account for multiple university studies. Partners needed access to approved folders, but raw sequencing data and consent-restricted records had to stay isolated.
🎯Business/Technical Objectives
Grant study teams least-privilege access to approved folders.
Prevent partner identities from traversing restricted raw-data paths.
Keep pipeline managed identities able to publish curated outputs.
Produce access evidence for quarterly ethics review.
✅Solution Using Path ACL
The platform team organized the lake into raw, validated, curated, and partner-export paths. Azure RBAC granted broad data-reader roles only to controlled service groups, while path ACLs refined read, write, and execute permissions at study directories. Default ACLs were applied to curated project folders so new outputs inherited the right group access. Azure CLI captured before-and-after ACL strings, updated managed identity entries, and tested parent directory traversal. Recursive ACL changes were limited to one study path at a time and logged with continuation details. Access review workbooks linked each project group to its approved paths and flagged stale object IDs for removal.
📈Results & Business Impact
Quarterly review time fell from five days to two days with exported ACL evidence.
No partner account could traverse restricted raw sequencing paths during validation tests.
Pipeline publication failures caused by missing permissions dropped by 62%.
Three stale collaborator IDs were removed before the next data-sharing cycle.
💡Key Takeaway for Glossary Readers
Path ACLs let one data lake serve many collaborators when access rules follow real project boundaries.
Case study 02
Streaming content royalties lake
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
ArcLight Streaming stored viewing events, royalty calculations, and partner extracts in the same lake. External production partners needed engagement data, but contract rates and payout calculations were confidential.
🎯Business/Technical Objectives
Share approved title-level engagement extracts with partners.
Block access to royalty calculation and contract-rate paths.
Keep Databricks jobs writing curated partner folders reliably.
Create a repeatable offboarding process for expired productions.
✅Solution Using Path ACL
Engineers separated royalty, engagement, and partner-export zones under distinct directory paths. Path ACLs granted partner groups read and execute access only to their export folders, while the Databricks managed identity kept write access to curated outputs. Default ACLs ensured new daily extracts inherited partner access without exposing adjacent folders. Azure CLI showed ACLs during release checks and removed partner entries recursively when a contract expired. Storage firewall and private endpoint rules restricted access to approved networks, and all ACL changes were tied to change tickets. Failed partner downloads were investigated by checking parent execute permissions before touching broader account roles.
📈Results & Business Impact
Partner extract delivery met the daily 7 a.m. deadline for 98% of publishing days.
Royalty calculation folders had zero unauthorized access findings in audit sampling.
Expired partner offboarding time dropped from two hours to 18 minutes.
Databricks permission-related job failures fell by 48% after default ACLs were corrected.
💡Key Takeaway for Glossary Readers
Path ACLs are practical guardrails when one lake contains both shareable analytics and contract-sensitive data.
Case study 03
Airport operations folder repair
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
RunwayPoint Airport moved data pipelines from user-managed service principals to managed identities. After the cutover, baggage and gate-status dashboards failed because curated lake folders still referenced old object IDs.
🎯Business/Technical Objectives
Restore dashboard reads before morning operations review.
Replace stale ACL entries with managed identity and group entries.
Avoid opening the entire storage account to all analysts.
Document a repeatable identity-migration checklist.
✅Solution Using Path ACL
Operators first used Azure CLI to show ACLs on the failed paths and parent directories. The output confirmed that old service-principal object IDs still had access, while new managed identities lacked execute permission on parent folders. The team updated ACLs on the affected curated folders, then ran a scoped recursive update only for child paths used by gate and baggage dashboards. They avoided account-key shortcuts and kept private endpoint restrictions unchanged. Pipeline owners tested reads from the managed identity, analysts tested dashboard access through their groups, and the old IDs were removed after successful validation. The checklist was updated to include ACL inventory before any identity migration.
📈Results & Business Impact
Gate-status dashboards recovered 47 minutes before the operations briefing.
No broad storage account access was granted during the incident.
Stale identity entries were removed from 1,240 child paths in one controlled change.
Future identity migrations gained a precheck that finds ACL drift in under 15 minutes.
💡Key Takeaway for Glossary Readers
Path ACL troubleshooting works best when operators inspect parent traversal, stale identities, and recursive scope before widening access.
Why use Azure CLI for this?
Azure CLI is useful for path ACLs because permission changes need exact evidence and repeatability. CLI commands can show ACL strings, set owners, apply access or default entries, and run recursive updates with continuation handling. That makes access reviews, incident response, and controlled rollout safer than relying on portal clicks alone.
CLI use cases
Show the ACL for a directory or file and capture owner, group, permissions, and named entries for evidence.
Set or update access ACL entries for a managed identity, security group, project team, or partner folder.
Apply recursive ACL changes to an existing folder tree while tracking continuation and failure output.
Remove stale user or service-principal entries after identity cleanup, offboarding, or partner-access expiry.
az storage fs directory list --account-name <storage-account> --file-system <file-system> --path <path> --auth-mode login --output table
az storage fs directorydiscoverStorage
Architecture context
In Azure architecture, path ACLs live in the storage data plane for accounts that use the hierarchical namespace. Azure RBAC can grant broad account or container permissions, while ACLs refine access at directory and file paths. ACL entries include owner, owning group, named users or groups, mask, other, and optional default entries for child paths. They are evaluated with identity, ownership, and traversal permissions. Path ACLs appear in Data Lake APIs, Azure CLI, Storage Explorer, SDKs, recursive ACL jobs, and lakehouse access runbooks.
Security
Security impact is direct because path ACLs decide data-plane access to files and directories. They should be used with Microsoft Entra identities, managed identities, Azure RBAC, private endpoints, storage firewalls, encryption, and audit logging. Common risk comes from granting broad group access, forgetting default ACL inheritance, exposing partner folders, or using account keys that bypass identity-based least privilege. Operators should review owner, group, mask, default, and other entries, and verify execute permission on parent directories. Sensitive datasets need periodic access recertification, evidence exports, and cleanup of stale user or service-principal object IDs. Review ACL evidence before sharing sensitive lake exports. Review every recursive change against data classification policy.
Cost
Cost impact is indirect but real. Path ACLs do not create a separate billing meter, yet poor access design can increase operational cost through failed pipeline retries, duplicated storage zones, emergency support, and unnecessary account sprawl. Recursive ACL updates over large folder trees consume time and operations, especially when repeated because the first change was too broad or incomplete. Strong ACL design can reduce duplicate data copies by allowing controlled shared access to the same lake. FinOps reviews should include access-driven duplication, stale partner extracts, failed job costs, and engineering hours spent resolving avoidable permission incidents. Track access-driven duplicate storage. Schedule carefully before applying.
Reliability
Reliability impact is direct for data pipelines and analytics jobs. A single ACL change on a parent directory can stop ingestion, notebook reads, Synapse queries, Databricks jobs, or downstream exports. Recursive ACL updates can also take time and may partially complete if interrupted, leaving inconsistent access across a large folder tree. Reliable operations use small test paths, continuation tokens, dry-run-style reviews, saved before-and-after evidence, and rollback ACL definitions. Teams should monitor failed reads, authorization errors, pipeline retries, and service-principal changes so access problems are detected before business reports miss their data windows. Test critical identities after each recursive change window. Test access with production service principals first.
Performance
Runtime performance impact is usually indirect because ACL checks are part of normal data access, not an analytics acceleration feature. The bigger performance effect appears in operations and troubleshooting. A missing execute permission can make jobs fail fast or retry repeatedly. A large recursive ACL update can run long, require continuation handling, and delay releases. Analytics performance may also suffer when teams copy data into separate folders to work around ACL problems instead of fixing access. Operators should measure authorization errors, recursive job duration, pipeline retry time, and query delays caused by permission-driven data movement. Review retries before tuning compute. Batch recursive updates during quiet operational windows.
Operations
Operators manage path ACLs by showing current permissions, setting owner or group, updating named entries, applying default ACLs, and running recursive changes for existing children. Azure CLI is valuable because it can record exact ACL strings and continuation information for change tickets. Storage Explorer helps visual inspection, but scripts are safer for repeatable environments. Day-to-day work includes checking whether the managed identity can traverse parent folders, validating group object IDs, comparing ACLs between raw and curated zones, and documenting which team owns each path. Every recursive change should include evidence, scope, and cleanup notes. Keep examples for common service identities. Record before-and-after evidence for rollback.
Common mistakes
Granting file read permission but forgetting execute permission on one or more parent directories.
Using broad storage account keys or account-level roles to bypass a path ACL problem instead of fixing it.