403 Access Denied authorization error when the sticky bit is enabled in ADLS Gen2

This article helps you understand the sticky bit and provides information about how to check this setting when you configure it in Azure Data Lake Storage (ADLS) Gen2 and get issues.

What is the sticky bit in ADLS Gen2?

ADLS Gen2 users often need to manage permissions for different users, and one way to do this is by using an access control list (ACL). ACL is a POSIX-like access control system with a specific setting called the sticky bit that can cause authorization failures. For more information about the permission control mode and the sticky bit, see Access control lists (ACLs) in Azure Data Lake Storage Gen2.

The sticky bit is an advanced feature that isn't necessary in the ACL setting of the ADLS Gen2 storage account. Instead, you can use the mask feature to limit the maximum permissions for named users, named groups, and the owning group. This works similarly to the sticky bit and is easily configured in the Azure portal.

403 Access Denied authorization error

Consider the following scenario:

• An ADLS Gen2 storage account has a container called container and a folder path called folder/child-folder.
• You use ACL as an authorization method.
• In the ACL setting of the ADLS Gen2 storage account, you're configured with Execute (X) permission on the root directory and folder and with Write and Execute (WX) permission on child-folder.
• The sticky bit is enabled on child-folder.
• You try to create or upload a new file, for example, test.txt, into the ADLS Gen2 Storage Account folder path container/folder/child-folder/.

In this scenario, you get a 403 Access Denied authorization error.

This error occurs for two reasons:

• You don't have enough permissions to access the folder path.
• You have enough permissions, but enabling the sticky bit causes you not to be the owner of this folder path.

Identify whether the sticky bit causes a 403 Access Denied error

Verify the ACL setting of the folder and the parent folders, and then compare it with the Common scenarios related to ACL permissions. If the permissions are enough, then the 403 error may be caused by the sticky bit.

Verify the sticky bit setting by using Azure CLI

There are many ways to check this setting, such as a REST API call, PowerShell command, and Azure CLI. We recommend the Azure CLI option because it doesn't require any extra software to be installed, and the command is easy to understand.

To verify the sticky bit setting by using Azure CLI, follow these steps:

1. Sign in to the Azure portal with your account. Make sure that this account has the Storage Blob Data Owner role assignment on the ADLS Gen2 storage account.

2. Select Cloud Shell from the Azure portal.

   

3. Use the following command to get the ACL and the sticky bit setting of the container/folder directory:

   az storage fs access show -p folder -f container --account-name account --auth-mode login
   

   To check the ACL and the sticky bit setting of the root directory, which is the container level ACL and the sticky bit setting, use the following command:

   az storage fs access show -p / -f container --account-name account --auth-mode login
   

   Here's a sample output:

   

   In the response JSON body, focus on permissions. It normally contains 9 or 10 bits with an extra "+" symbol. For more information about these letters, see Users and identities.

   The previous example indicates that all user permissions are enabled, and the sticky bit is enabled. For more information about how to read this permission notation, see Notation of traditional Unix permissions.

   The ninth letter has four possible values: "-", "x", "t", and "T". If the value of this letter is "t" or "T", it means that the sticky bit is enabled. The "t" is "x" with the sticky bit enabled, and "T" is "-" with the sticky bit enabled.

   "rwxrwxrwt" can be explained by the following:

   • r,w, and x permissions are enabled for the Owner.
   • r,w, and x permissions are enabled for the Owning group.
   • r,w, and x permissions are enabled for Other users, and the sticky bit is enabled.

   To understand it better, here's another example for "rwxr-xr-T":

   • r,w, and x permissions are enabled for the Owner.
   • r and x permissions are enabled for the Owning group.
   • Only r permission is enabled for Other users, and the sticky bit is enabled.

   According to Short forms for permissions, short form permission is calculated for every group of three letters ("r" as 4, "w" as 2, and "x "as 1). So, "rw-rwx--x" will be equal to 4+2+0, 4+2+1, 0+0+1, 671. Based on this calculation rule, you only need to add the fourth letter at the beginning. If the sticky bit is enabled, set it as 1. If the sticky bit is disabled, set it as 0.

   Here are some examples:

   • rwxrwxrwt => 1777
   • rwxr-xr-T => 1754
   • rw-rwx--x => 0671

Disable/Enable the sticky bit setting

To disable/enable the sticky bit setting, set permissions to expected values.

The Azure account used to modify this setting must have the Storage Blob Data Owner role on the target ADLS Gen2 storage account. There are many possible ways to modify the sticky bit setting. Here are the supported SDKs:

Here's an example of disabling/enabling the sticky bit setting with Azure CLI.

1. Sign in to the Azure portal with your account that has the Storage Blob Data Owner role assignment on the target ADLS Gen2 storage account.

2. Select Cloud Shell from the Azure portal.

   

3. To set the ACL and the sticky bit setting of the container/folder directory to the "rwxrwxrwt" permissions and to enable the sticky bit, use the following command:

   az storage fs access set --permissions rwxrwxrwt -p folder -f container --account-name account --auth-mode login
   

   To modify the setting of the root directory, which is the container level ACL and the sticky bit setting, use the following command:

   az storage fs access set --permissions rwxrwxrwt -p / -f container --account-name account --auth-mode login
   

   The {permission notation} in the previous command can accept both long and short-form notations. This means that the following command is also qualified:

   az storage fs access set --permissions 1776 -p folder -f container --account-name account --auth-mode login
   

   Here's an example output:

   

Contact us for help

If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure feedback community.