Adding Default acl permission on the SFTP enabled storage account container causing it to fail.

Question

Adding Default acl permission on the SFTP enabled storage account container causing it to fail.

Sumit Gaur 455

Hi,

We have an SFTP-enabled Azure Storage account, and we are using ACLs to manage access to different subfolders inside our container.

Our structure looks like below, where within a single container we have created multiple subfolders that act as root directories for different users:

blobcontainer
├── user1/
│   ├── incoming/
│   └── outgoing/
└── user2/
    ├── incoming/
    └── outgoing/

In this setup, we have multiple users configured within the same container, and their access is controlled using ACLs.

To configure access, we perform the following steps:

Create a new local user with ACL authorization enabled and set the root directory to: /blobcontainer/user1
We also have another local user which acts as an admin SFTP user with full access to all containers.
We connect to the storage account using the admin account: sftp stasftp.<container-name>******@stasftp.blob.core.windows.net

This connects the admin user to the container where access needs to be managed.

We then run the following commands:

List all directories: ls
Allow admin to modify ownership: chmod 001 .
Assign ownership of the target directory to the user (e.g., UID 1000): chown 1000 user1
Recursively assign ownership to subdirectories: chown 1000 user1/*

We repeat these steps for each user.

This setup works fine, and we are able to control user access to their respective directories.

However, we are facing an issue when files are uploaded using Azure native services like Logic Apps or Azure Functions. The uploaded blobs do not have the required permissions, and the SFTP user is unable to access them.

To resolve this, we tried adding Default ACLs for the local user via Azure Portal and Azure Storage Explorer. This successfully assigns permissions to newly created files.

However, it introduces a new issue:

SFTP login starts failing with the error: "The requested container does not exist or is not accessible. Authentication failed."
The other user on the container level has execute x permission so it should generally traverse the directory.
If we remove the Default ACL, login starts working again.

Problem summary:

Without Default ACL → Login works, but new files are not accessible
With Default ACL → File access works, but SFTP login fails

Has anyone faced a similar issue or knows the correct way to handle ACLs for files uploaded via Azure services in an SFTP-enabled storage account?

Vinodh247 42,611 Reputation points MVP Volunteer Moderator

2026-04-18T15:52:00.1133333+00:00
Hi ,

Thanks for reaching out to Microsoft Q&A.

This is a known behaviour with SFTP on Azure Blob Storage SFTP when using POSIX-style ACLs.

The root cause is that adding default ACLs at the container or root directory level can unintentionally break the execute (x) permission chain required for directory traversal during login. Even if the user has access to their target folder, SFTP authentication fails if any parent path (including the container root) does not have proper x permission for that user or group.

In your case, when you add default ACLs, they are likely overriding or not preserving the required x permission on /blobcontainer or /blobcontainer/user1, causing the login failure.

Correct approach:

Do not set default ACLs at the container root unless you explicitly include x for all required identities.

Instead, set default ACLs only at the user root folder level (for example /blobcontainer/user1) with:

user:<uid>:rwx

`default:user:<uid>:rwx`

Ensure the full path hierarchy has at least --x (execute) permission for the user:

container -> user folder -> subfolders

Avoid using chmod 001 . at root unless you fully understand its impact, as it removes read/write and keeps only execute, which can interfere with ACL evaluation.

Apply default ACLs at the user folder level, not container level, and ensure execute permission is intact across the full directory path. This keeps both login and file access working.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.
Sumit Gaur 455 Reputation points

2026-04-18T16:48:01.93+00:00

Hi @Vinodh247

The default ACL is being set at the user-level directory (blobcontainer/user1) rather than at the container level and that's when i get login issues. The container itself provides execute (--x) permission to others, which technically allows traversal for user1

when I attempted to set default ACLs on the incoming and outgoing** folders unde `user1`, the login doesn't appear anymore.

However, when a file is uploaded by a different user, the default ACL is not properly applied to the file specifically, the expected permissions are not set for the owner. i could only see rw for the owner instead of rwx

The setup only works correctly when I manually propagate the ACL on the directory after the file is uploaded which make sense as it overrides everything. .
Sumit Gaur 455 Reputation points

2026-04-18T17:48:51.6233333+00:00

Hi @Vinodh247

I was able to partially resolve the issue by applying an appropriate ACL mask. With this change, when a file is uploaded by another SFTP user, user1 is effectively treated as the owner and can access the file as expected.

However, this approach does not work when the file is uploaded via a Logic App. In that case, the ownership and access behavior differ, and user1 is still unable to access the file despite the mask configuration.
Vinodh247 42,611 Reputation points MVP Volunteer Moderator

2026-04-19T10:34:27.89+00:00
Your mask fix works for SFTP because files have a proper POSIX owner (UID). But when files come from Logic Apps, they are created using an Azure identity, not an SFTP user, so ownership mapping does not apply.

Fix:

Do not rely on ownership or mask alone

Set default ACL on the user folder (/user1) with explicit entry:

default:user:1000:rwx

default:mask:rwx

If it still fails, inheritance is bypassed -> use a post-processing step (Function/Script) to set ACL explicitly after file creation.

note: Logic Apps uploads require explicit ACL entries, not owner-based access.
Venkatesan S 8,235 Reputation points Microsoft External Staff Moderator

2026-04-20T01:10:10.81+00:00

Hi Sumit Gaur,

Just checking in to see if you had a chance to see the previous response posted by Vinodh247.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Kindly let us know if the above helps or you need further assistance on this issue and leave the comment.
Sumit Gaur 455 Reputation points

2026-04-20T12:22:57.9266667+00:00

Hi @Vinodh247 - i did the above steps but it didn't work on the SFTP-to-SFTP setup.

i uploaded a file via a SFTP admin user which has full access to the container by applying above defaults on the user1/outgoing directory but the permission on the file becomes ---------, hence not able to read it. what can be done in case of end to end SFTP communication where uploader/downloader are both SFTP clients.

the partial success i got doesn't seem to work anymore as well.
Venkatesan S 8,235 Reputation points Microsoft External Staff Moderator

2026-04-21T01:07:54.3633333+00:00
Hi Sumit Gaur,

Thanks for reaching out in Microsoft Q&A forum,

What you’re seeing is expected behavior with SFTP on Azure Blob Storage, because Azure SFTP only emulates POSIX permissions and doesn’t behave exactly like a traditional Linux file system.

Why files sometimes show --------- or are not accessible

When a file is uploaded, Azure calculates its permissions by combining three things:

The creation mode the uploader sends (similar to a umask hint).

The ACL mask on the parent directory.

Any default ACLs set on that directory.

If the mask or default ACLs are too restrictive, the result can be permissions that look like --------- or rw-------, even if you’ve set default:user:1000:rwx. This is not a bug; it’s how Azure SFTP evaluates ACLs at file‑creation time.

ownership works in Azure SFTP

Azure SFTP always assigns ownership to the identity that performs the upload:

If another SFTP user uploads > the file owner is that SFTP user’s UID.

If Logic Apps, Functions, or other Azure services upload > the file is owned by an internal Azure identity, not by any local SFTP user.

Because of that, access is not reliably controlled by “ownership”. Instead, it is controlled by the ACL entries and mask that exist at the time the file is created.

That’s why you see two main behaviors:

Without default ACLs > SFTP login works (parents have --x), but newly uploaded files may not be accessible because there are no explicit ACL grants.

With default ACLs at the wrong level > the ACL evaluation can unintentionally remove --x on a parent path, so SFTP login fails with “container does not exist or is not accessible / authentication failed.”

Instead of trying to manage ownership or rely on chown after upload, the supported pattern is:

Treat folders as ACL‑controlled shared locations, not user‑owned directories Give specific users and services explicit ACL entries on the folder, and don’t assume ownership alone will grant access.

Keep execute (x) on all parent paths Make sure:

/blobcontainer has at least --x for identities that need to traverse.

/blobcontainer/user1 has at least --x. This keeps the SFTP login path (container > user1 > outgoing) always traversable.

Apply default ACLs only at the working folder For a structure like:
/blobcontainer/user1/outgoing
Set ACLs only here, not at the container root unless you carefully preserve --x:

user:1000:rwx < user1

user:1001:rwx < admin

mask:rwx

default:user:1000:rwx

default:user:1001:rwx

default:mask:rwx

This way, any new file created under /outgoing inherits the correct ACLs, regardless of who uploads it.

Do not depend on ownership Files uploaded by other SFTP users, Logic Apps, or Azure Functions will all have different owners. Ownership is not a reliable access‑control mechanism in Azure SFTP; explicit ACL entries are.

Ensure explicit ACL permissions exist for all required users and services with the right ACLs and masks on the folder, both SFTP and Logic‑App uploads will have consistent access, because the engine is checking ACLs, not trying to guess ownership‑based sharing.

Azure Blob Storage SFTP works best when access is designed around explicit ACL permissions, not Linux‑style owner/group behavior. Once you:

Keep --x on parent paths for login.

Put default ACLs only at the working folder level.

Explicitly grant access to every user or service that needs it (via ACL entries, not ownership).

you should see both login and file access work consistently for SFTP‑to‑SFTP, admin‑to‑user, and Logic‑App‑to‑SFTP flows.

Reference:

Connect to Azure Blob Storage from an SFTP client - Azure Storage | Microsoft Learn

Azure Blob Storage SFTP: General Availability of ACLs (Access Control Lists) of local users | Microsoft Community Hub

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Sumit Gaur 455 Reputation points

2026-04-25T04:41:54.16+00:00
Hi @Venkatesan S

I implemented a setup using a mix of container-level permissions and ACLs. It seems to be working as expected, but I wanted to confirm if this is the right approach.

The method suggested earlier works; however, there’s an issue, if a Logic App uploads a file, it fails when trying to read it afterward.

Here’s what I did:

While creating the new user, I granted read permission at the blob container level.

Then I applied the following commands at the root and user directory levels to restrict access to specific directories:

chmod 001 .

Executed on the root directory using a superuser.

This sets permissions so that others only have execute (traverse) permission.

chown 1000 user1

Assigns ownership of the user directory to the specific user.

chown 1000 user1/*

Assigns ownership of all subdirectories/files under the user directory.

With this setup:

The user can download files from their own directory.

The user is prevented from traversing into other users’ directories within the same container.

Let me know if this aligns with best practices or if there’s a cleaner way to handle this?
Praveen Bandaru 11,555 Reputation points Microsoft External Staff Moderator

2026-04-30T23:41:27.4766667+00:00

Hello Sumit Gaur

Based on your description, combining container-level RBAC permissions with directory-level ACLs is a valid approach and matches Azure Data Lake Storage Gen2’s layered access control. Using execute permissions at the root and assigning ownership at the user directory level follows POSIX-style permission models, and it’s good to see this setup restricts users from accessing other directories.

For better consistency and easier maintenance, consider using default ACLs on user directories instead of manual ownership changes like chown. Default ACLs automatically apply the correct permissions to new files and folders, reducing manual updates and minimizing access issues.

If your Logic App can upload a file but cannot read it afterward, this likely relates to how permissions are set during file creation. The file inherits permissions from the parent directory’s default ACL, so if the Logic App’s identity isn’t included, it may lack read permissions. Make sure the Logic App identity has both read permissions on the file and execute permissions on all parent directories.

To resolve this, add the Logic App identity to the ACL and default ACL of the target directory with the necessary permissions. Also, using Microsoft Entra ID groups for user access and Managed Identities for applications is recommended, as this simplifies management and supports scalability.
Praveen Bandaru 11,555 Reputation points Microsoft External Staff Moderator

2026-05-02T18:35:09.5+00:00

Hello Sumit Gaur

I just wanted to follow up and see if you had a chance to review my answer to your question. Please let us know if you found it useful, and don't hesitate to contact us if you have any further questions.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.
Sumit Gaur 455 Reputation points

2026-05-04T09:09:02.51+00:00

Hi Praveen,

Let me try this to see if i don't need don't need to apply manual permission anymore.
Praveen Bandaru 11,555 Reputation points Microsoft External Staff Moderator

2026-05-05T23:58:56.8033333+00:00

Hello Sumit Gaur

Thank you for getting back to me. Please review and let me know your feedback. If you need any assistance, feel free to contact us.

1 answer

Your answer

Vinodh247 42,611 Reputation points MVP Volunteer Moderator

2026-04-18T15:52:00.1133333+00:00

Hi ,

Thanks for reaching out to Microsoft Q&A.

This is a known behaviour with SFTP on Azure Blob Storage SFTP when using POSIX-style ACLs.

The root cause is that adding default ACLs at the container or root directory level can unintentionally break the execute (x) permission chain required for directory traversal during login. Even if the user has access to their target folder, SFTP authentication fails if any parent path (including the container root) does not have proper x permission for that user or group.

In your case, when you add default ACLs, they are likely overriding or not preserving the required x permission on /blobcontainer or /blobcontainer/user1, causing the login failure.

Correct approach:

Do not set default ACLs at the container root unless you explicitly include x for all required identities.

Instead, set default ACLs only at the user root folder level (for example /blobcontainer/user1) with:

user:<uid>:rwx

`default:user:<uid>:rwx`

Ensure the full path hierarchy has at least --x (execute) permission for the user:

container -> user folder -> subfolders

Avoid using chmod 001 . at root unless you fully understand its impact, as it removes read/write and keeps only execute, which can interfere with ACL evaluation.

Apply default ACLs at the user folder level, not container level, and ensure execute permission is intact across the full directory path. This keeps both login and file access working.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.
Sumit Gaur 455 Reputation points

2026-04-18T16:48:01.93+00:00

Hi @Vinodh247

The default ACL is being set at the user-level directory (blobcontainer/user1) rather than at the container level and that's when i get login issues. The container itself provides execute (--x) permission to others, which technically allows traversal for user1

when I attempted to set default ACLs on the incoming and outgoing** folders unde `user1`, the login doesn't appear anymore.

However, when a file is uploaded by a different user, the default ACL is not properly applied to the file specifically, the expected permissions are not set for the owner. i could only see rw for the owner instead of rwx

The setup only works correctly when I manually propagate the ACL on the directory after the file is uploaded which make sense as it overrides everything. .
Sumit Gaur 455 Reputation points

2026-04-18T17:48:51.6233333+00:00

Hi @Vinodh247

I was able to partially resolve the issue by applying an appropriate ACL mask. With this change, when a file is uploaded by another SFTP user, user1 is effectively treated as the owner and can access the file as expected.

However, this approach does not work when the file is uploaded via a Logic App. In that case, the ownership and access behavior differ, and user1 is still unable to access the file despite the mask configuration.
Vinodh247 42,611 Reputation points MVP Volunteer Moderator

2026-04-19T10:34:27.89+00:00

Your mask fix works for SFTP because files have a proper POSIX owner (UID). But when files come from Logic Apps, they are created using an Azure identity, not an SFTP user, so ownership mapping does not apply.

Fix:

Do not rely on ownership or mask alone

Set default ACL on the user folder (/user1) with explicit entry:

default:user:1000:rwx

default:mask:rwx

If it still fails, inheritance is bypassed -> use a post-processing step (Function/Script) to set ACL explicitly after file creation.

note: Logic Apps uploads require explicit ACL entries, not owner-based access.
Venkatesan S 8,235 Reputation points Microsoft External Staff Moderator

2026-04-20T01:10:10.81+00:00

Hi Sumit Gaur,

Just checking in to see if you had a chance to see the previous response posted by Vinodh247.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Kindly let us know if the above helps or you need further assistance on this issue and leave the comment.
Sumit Gaur 455 Reputation points

2026-04-20T12:22:57.9266667+00:00

Hi @Vinodh247 - i did the above steps but it didn't work on the SFTP-to-SFTP setup.

i uploaded a file via a SFTP admin user which has full access to the container by applying above defaults on the user1/outgoing directory but the permission on the file becomes ---------, hence not able to read it. what can be done in case of end to end SFTP communication where uploader/downloader are both SFTP clients.

the partial success i got doesn't seem to work anymore as well.
Sumit Gaur 455 Reputation points

2026-04-25T04:41:54.16+00:00

Hi @Venkatesan S

I implemented a setup using a mix of container-level permissions and ACLs. It seems to be working as expected, but I wanted to confirm if this is the right approach.

The method suggested earlier works; however, there’s an issue, if a Logic App uploads a file, it fails when trying to read it afterward.

Here’s what I did:

While creating the new user, I granted read permission at the blob container level.

Then I applied the following commands at the root and user directory levels to restrict access to specific directories:

chmod 001 .

Executed on the root directory using a superuser.

This sets permissions so that others only have execute (traverse) permission.

chown 1000 user1

Assigns ownership of the user directory to the specific user.

chown 1000 user1/*

Assigns ownership of all subdirectories/files under the user directory.

With this setup:

The user can download files from their own directory.

The user is prevented from traversing into other users’ directories within the same container.

Let me know if this aligns with best practices or if there’s a cleaner way to handle this?
Praveen Bandaru 11,555 Reputation points Microsoft External Staff Moderator

2026-04-30T23:41:27.4766667+00:00

Hello Sumit Gaur

Based on your description, combining container-level RBAC permissions with directory-level ACLs is a valid approach and matches Azure Data Lake Storage Gen2’s layered access control. Using execute permissions at the root and assigning ownership at the user directory level follows POSIX-style permission models, and it’s good to see this setup restricts users from accessing other directories.

For better consistency and easier maintenance, consider using default ACLs on user directories instead of manual ownership changes like chown. Default ACLs automatically apply the correct permissions to new files and folders, reducing manual updates and minimizing access issues.

If your Logic App can upload a file but cannot read it afterward, this likely relates to how permissions are set during file creation. The file inherits permissions from the parent directory’s default ACL, so if the Logic App’s identity isn’t included, it may lack read permissions. Make sure the Logic App identity has both read permissions on the file and execute permissions on all parent directories.

To resolve this, add the Logic App identity to the ACL and default ACL of the target directory with the necessary permissions. Also, using Microsoft Entra ID groups for user access and Managed Identities for applications is recommended, as this simplifies management and supports scalability.
Praveen Bandaru 11,555 Reputation points Microsoft External Staff Moderator

2026-05-02T18:35:09.5+00:00

Hello Sumit Gaur

I just wanted to follow up and see if you had a chance to review my answer to your question. Please let us know if you found it useful, and don't hesitate to contact us if you have any further questions.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community.
Sumit Gaur 455 Reputation points

2026-05-04T09:09:02.51+00:00

Hi Praveen,

Let me try this to see if i don't need don't need to apply manual permission anymore.
Praveen Bandaru 11,555 Reputation points Microsoft External Staff Moderator

2026-05-05T23:58:56.8033333+00:00

Hello Sumit Gaur

Thank you for getting back to me. Please review and let me know your feedback. If you need any assistance, feel free to contact us.

Answer 1

Sumit Gaur hi & thx for join me here at Q&A portal,

I guess it is SFTP limitation, not ur chmod/chown flow being wrong.

Azure Blob SFTP with local users currently does not support Default ACLs or extra named ACL entries in the access path, if any directory in the login path or home directory has Default ACLs/additional ACLs, SFTP can fail even when permissions look correct, which matches ur “default ACL added > login fails” behavior.

Only basic POSIX entries like user::, group::, other:: are safe for SFTP local-user access, Default ACLs are the problem. emove Default ACLs from the container/user path and keep access controlled with ownership + normal access ACLs only. For files uploaded by Logic Apps/Functions, dont rely on Default ACL inheritance, instead run a post-upload permission fix, like an Event Grid trigger to Function that sets owner/permissions on the new blob/path, or make the uploader write with the correct identity/ACL model. If u need real inherited ACL behavior across REST/SDK and SFTP, look at Entra ID-based SFTP access but its still preview, so test hard before prod.

Default ACLs break local-user SFTP login, remove them and handle new blob permissions

rgds, Alex

&

if my answer helps pls accept it.

Share via

Adding Default acl permission on the SFTP enabled storage account container causing it to fail.

1 answer

Your answer