When blobfuse2 use --use-adls=true, there have AuthorizationFailure

[Rohan128]

blobfuse2 mount /mnt/batch/tasks/fsmounts/internal-timeseries --config-file=output.yaml --use-adls=true

Error: failed to initialize new pipeline [failed to authenticate azstorage credentials with error [Datalake::TestPipeline : [AuthorizationFailure]]]

However the command succeed without the --use-adls=true

blobfuse2 mount /mnt/batch/tasks/fsmounts/internal-timeseries --config-file=output.yaml

Storage Account configuration looks fine, blobfuse2 configuration looks fine.
Please help to check it.

[Rohan128]

[Rohan128]

[souravgupta-msft]

@Rohan128, kindly redact your account key or other credentials before sharing here. I have removed the config file image from your comment.

[souravgupta-msft]

Is your account HNS enabled?

[Rohan128]

Yes, it is HNS enabled.

[FGS-SWirt]

I am also encountering the same issue. This has been working for quite a while now with no changes on my end, other than updating to blobfuse2 v2.5.0 when it was released. It worked fine up until very recently, so this seems likely to be something changed on the Azure side of things.

Relevant log entry:

Aug 27 13:40:11 myhostname blobfuse2[87291]: [/path/to/storage] LOG_ERR [datalake.go (203)]: Datalake::TestPipeline : Failed to validate account with given auth GET https://<redacted account>.dfs.core.windows.net/<redacted container>#012--------------------------------------------------------------------------------#012RESPONSE 403: 403 This request is not authorized to perform this operation.#012ERROR CODE: AuthorizationFailure#012--------------------------------------------------------------------------------#012{#012 "error": {#012 "code": "AuthorizationFailure",#012 "message": "This request is not authorized to perform this operation.\nRequestId:f7b194ea-001f-0014-3c58-17a891000000\nTime:2025-08-27T13:40:11.9667837Z"#012 }#012}#012--------------------------------------------------------------------------------

Some of the properties on the storage account:

[souravgupta-msft]

Yes, it is HNS enabled.

@Rohan128, I saw that you are using block as account type in your config. Please update that to adls and retry. Also, the adls endpoints are of the format *.dfs.core.windows.net, unless you are using private endpoints.

[souravgupta-msft]

@FGS-SWirt, can you please share the config file and mount command you are using. Kindly make sure to redact the account credentials in the config.

[FGS-SWirt]

I was able to fix my issue, at least for now. The only change within the blobfuse2 configuration that I made was using the dfs.core.windows.net endpoint instead of the blob.core.windows.net endpoint (which had been working just fine for over a year; this change alone did not fix the issue). The primary issue here was with the configuration of the storage account in Azure. It appears some default behavior may have changed in regards to how allow networks/IPs were handled, but I can't prove that.

Some background:

• I have two different VMs in Azure. One mounts a blob with HNS enabled, and one mounts a blob without HNS enabled
• Both have been working just fine into roughly a week ago, upon which the VM that connects to HNS enabled storage started giving the 403 errors mentioned above.

After doing some more digging, I realized that the blob that was still working fine had the Azure VM's VNet in the list of allowed virtual networks (Storage Account -> Security + Networking -> Networking -> click Manage under "Resource settings: Virtual networks, IP addresses, and exceptions). The HNS-enabled blob, for some reason, did not have that one present, but instead had a different virtual network listed.

Once I added the VM's VNet (and allowing it to create a service endpoint), then blobfuse2 started working again. The odd thing is that I believe it was working previously without the VM's VNet being in the list of allowed virtual networks. Perhaps something changed on the Azure side and it was inherently trusted because it was an Azure VM, but now it isn't?

@Rohan128 I would try looking at the setting I mentioned above and make sure your VM's public IP address/range is allowed. Here is a screenshot of where I'm talking about if the text wasn't clear:

After clicking Manage, you can see the allowed IPs and networks:

[vibhansa-msft]

If you are mounting HNS account, kindly use "type: adls" as mentioned by Sourav earlier, as certain directory level operations like rename/delete might have issues in wrong mode. If you are not sure about the account type, then leave it to blobfuse which can auto detect it. You shall skip the endpoint config as well, and let blobfuse identify it correctly based on account type. Only place where you need to define endpoint is when you are not using standard endpoints or using private/sovereign clouds.

[vibhansa-msft]

If above information is helpful and you have no further queries on this, kindly close the report here.

[vibhansa-msft]

Closing this item here. If you have any further queries, feel free to reopen or create a new item.