Is your feature request related to a problem? Please describe.
This is a follow-up of the initial feature request #38912
Based on the new capability added when completing the above mentioned issue, the check whether HNS is enabled can be done relatively straightforward:
createBlobContainerClient(location, Optional.empty())
.getServiceClient()
.getAccountInfo()
.isHierarchicalNamespaceEnabled();
This approach needs though elevated permissions for the service principal calling it ("Storage Account Contributor" role) AND it does not work unfortunately for vended credentials (which are directory scoped, not storage account scoped).
Describe the solution you'd like
Provide an API which can be used without any elevated permissions (having "Storage Blob Data Reader" role should be enough) AND which works as well with SAS vended credentials for figuring out whether the storage account corresponding to an Azure location has HNS enabled.
Describe alternatives you've considered
Based on the new capability added when completing the issue #38912, the check whether HNS is enabled can be done relatively straightforward:
createBlobContainerClient(location, Optional.empty())
.getServiceClient()
.getAccountInfo()
.isHierarchicalNamespaceEnabled();
However, as described in trinodb/trino#27278 , this approach needs unfortunately elevated permissions.
"message":"Checking whether hierarchical namespace is enabled for the location abfs://xxx/.... failed",
"cause":{
"type":"com.azure.storage.blob.models.BlobStorageException",
"message":"If you are using a StorageSharedKeyCredential, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate method call.\nIf you are using a SAS token, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate generateSas method call.\nPlease remember to disable 'Azure-Storage-Log-String-To-Sign' before going to production as this string can potentially contain PII.\nIf you are using a StorageSharedKeyCredential, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate method call.\nIf you are using a SAS token, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate generateSas method call.\nPlease remember to disable 'Azure-Storage-Log-String-To-Sign' before going to production as this string can potentially contain PII.\nStatus code 403, \"•<?xml version=\"1.0\" encoding=\"utf-8\"?><Error><Code>AuthorizationPermissionMismatch</Code><Message>This request is not authorized to perform this operation using this permission.\nRequestId:9dd14fea-f01e-0067-38ce-520758000000\nTime:2025-11-11T05:48:27.2395973Z</Message></Error>\"",
NOTE the Status code 403 in the above message.
This happens when the Azure role "Storage Account Contributor" is missing on the service principal for storage account on which we're checking whether the hierarchical namespace is enabled.
That's the approach the project trinodb/trino currently uses to figure out whether a storage account has HNS enabled:
BlockBlobClient blockBlobClient = createBlobContainerClient(location, Optional.empty())
.getBlobClient("/")
.getBlockBlobClient()
.blockBlobClient.exists();
With the advent of vended credentials, the above mentioned approach doesn't work anymore because the vended credentials are directory scoped and not container scoped.
What we're currently trying is a rather non-conventional approach on checking via getAccessControl() method the error code to figure out whether we're dealing of not with a HNS enabled storage account:
private boolean isHierarchicalNamespaceEnabledWithVendedCredentials(AzureLocation location)
throws IOException
{
try {
String path = location.path();
while (path.endsWith("/")) {
path = path.substring(0, path.length() - 1);
}
DataLakeFileSystemClient fileSystemClient = createFileSystemClient(location, Optional.empty());
fileSystemClient.getDirectoryClient(path).getAccessControl();
return true;
}
catch (DataLakeStorageException e) {
// getAccessControl() is only supported on HNS-enabled accounts; flat namespace returns HierarchicalNamespaceNotEnabled
if ("HierarchicalNamespaceNotEnabled".equals(e.getErrorCode())) {
return false;
}
// Path does not exist yet (e.g. creating a new nested directory), but the account supports HNS
if (e.getStatusCode() == 404) {
return true;
}
throw new IOException("Checking whether hierarchical namespace is enabled for the location %s failed".formatted(location), e);
}
catch (RuntimeException e) {
throw new IOException("Checking whether hierarchical namespace is enabled for the location %s failed".formatted(location), e);
}
}
Related PR trinodb/trino#29947
Additional context
Add any other context or screenshots about the feature request here.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report
Is your feature request related to a problem? Please describe.
This is a follow-up of the initial feature request #38912
Based on the new capability added when completing the above mentioned issue, the check whether HNS is enabled can be done relatively straightforward:
This approach needs though elevated permissions for the service principal calling it ("Storage Account Contributor" role) AND it does not work unfortunately for vended credentials (which are directory scoped, not storage account scoped).
Describe the solution you'd like
Provide an API which can be used without any elevated permissions (having "Storage Blob Data Reader" role should be enough) AND which works as well with SAS vended credentials for figuring out whether the storage account corresponding to an Azure location has HNS enabled.
Describe alternatives you've considered
Based on the new capability added when completing the issue #38912, the check whether HNS is enabled can be done relatively straightforward:
However, as described in trinodb/trino#27278 , this approach needs unfortunately elevated permissions.
NOTE the Status code 403 in the above message.
This happens when the Azure role "Storage Account Contributor" is missing on the service principal for storage account on which we're checking whether the hierarchical namespace is enabled.
That's the approach the project
trinodb/trinocurrently uses to figure out whether a storage account has HNS enabled:With the advent of vended credentials, the above mentioned approach doesn't work anymore because the vended credentials are directory scoped and not container scoped.
What we're currently trying is a rather non-conventional approach on checking via
getAccessControl()method the error code to figure out whether we're dealing of not with a HNS enabled storage account:Related PR trinodb/trino#29947
Additional context
Add any other context or screenshots about the feature request here.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report