File permissions on Data Lake Storage deliveries

On an Azure storage account with hierarchical namespace (Data Lake Storage Gen2) enabled, every file and directory carries POSIX-style permissions and access control lists (ACLs) alongside Azure's role-based access control. If the people or service principals reading your container rely on those ACLs, files delivered by a channel are not readable by them until the ACLs say so - this guide explains what a delivered file's permissions look like and how to set access up once so it applies to every future delivery.

Accounts without hierarchical namespace have no POSIX ACLs, so none of this applies there - access is governed entirely by Azure RBAC and shared keys.

First: does this affect you at all?

Azure evaluates RBAC first, ACLs second. A principal holding a data-plane role such as Storage Blob Data Reader or Storage Blob Data Contributor on the account or container can read delivered files regardless of any ACL. If everything that reads your container uses RBAC roles or the account key, delivered files are already readable and you can stop here.

ACLs matter when you grant access the POSIX way - a named user, group or service principal given fine-grained rights on specific directories, without a broad RBAC role.

What a delivered file looks like

The channel authenticates with your storage account key, so Azure records the delivered file as owned by the built-in superuser:

• Owner: $superuser   Group: $superuser
• Permissions: rw-r-----

No named principals appear in the file's ACL unless the destination directory says otherwise (next section). A principal without an RBAC role and without an ACL entry gets permission denied - the classic symptom is a Databricks job or a service principal that can list the directory but cannot open the files DocEvent just delivered.

Grant access once, with default ACLs

A directory's default ACL is a template stamped onto everything created inside it. Files delivered by a channel inherit the destination directory's default ACL entries - so setting them once makes every future delivery readable, with no per-file work.

Using the Azure CLI, grant a principal read on future files and access to the directory itself (readers also need execute on every directory in the path to reach a file):

az storage fs access set \
  --acl "user::rwx,group::r-x,other::---,user:<object-id>:r-x,default:user::rwx,default:group::r-x,default:other::---,default:user:<object-id>:r--" \
  -p path/to/deliveries -f <container> \
  --account-name <account> --auth-mode login

Replace <object-id> with the Entra object ID of the user, group or service principal. The same entries can be set in Azure Storage Explorer or the portal under Manage ACL - tick "Default" for the entries that should apply to new children.

Files delivered before the default ACL existed do not pick it up retroactively - backfill them once with az storage fs access update-recursive.

Per-file ACLs do not survive redelivery

Setting an ACL directly on a delivered file works - until the channel delivers a file with the same name again. Redelivery replaces the file, and the replacement carries only the owner permissions plus whatever the directory's default ACL grants; a manually added per-file entry is gone. Channels overwrite by design (a corrected invoice or re-issued EDI document arrives under the same name), so treat per-file ACL edits as temporary and put durable grants in the directory's default ACL instead.

Still stuck?

If a reader still gets permission denied, walk the path: the principal needs --x on the container root and every intermediate directory, and r-- on the file (via the default ACL). Check the effective entries with az storage fs access show -p <path>. Or contact support.