azurerm_storage_account with shared_access_key_enabled and blob restore_policy set fails #24568
Comments
|
@ned1313 I've just tried your above configuration locally, and the apply succeeded for me. The provider reaches to the file service because the storage |
|
@magodo You're right, I just ran the code I pasted above and it worked without issue. I thought a little more about what I was actually doing, and I realized I had run an $ terraform apply -replace="azurerm_storage_account.main"
...
azurerm_storage_account.main: Destroying... [id=/subscriptions/XXXX/resourceGroups/abac4mhvwe/providers/Microsoft.Storage/storageAccounts/abac4mhvwe]
azurerm_storage_account.main: Destruction complete after 3s
azurerm_storage_account.main: Creating...
azurerm_storage_account.main: Still creating... [10s elapsed]
azurerm_storage_account.main: Still creating... [20s elapsed]
│ Error: retrieving share properties for Storage Account (Subscription: "XXXX"
│ Resource Group Name: "abac4mhvwe"
│ Storage Account Name: "abac4mhvwe"): storage.FileServicesClient#GetServiceProperties: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="ResourceNotFound" Message="The specified resource does not exist.\nRequestId:2c0aaf14-201a-0040-38a1-4f8e83000000\nTime:2024-01-25T15:16:33.9699991Z"
│
│ with azurerm_storage_account.main,
│ on main.tf line 27, in resource "azurerm_storage_account" "main":
│ 27: resource "azurerm_storage_account" "main" {To recreate the issue, run the following commands with this configuration: provider "azurerm" {
features {}
# Set storage access to use Azure AD instead of storage key SAS
storage_use_azuread = true
}
data "azurerm_subscription" "main" {}
# Use random string to create naming suffix
resource "random_string" "main" {
length = 6
special = false
upper = false
}
locals {
naming_string = "abac${random_string.main.result}"
}
# Create resource group
resource "azurerm_resource_group" "main" {
name = local.naming_string
location = "eastus"
}
# Create storage account
resource "azurerm_storage_account" "main" {
name = local.naming_string
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
account_tier = "Standard"
account_kind = "StorageV2"
account_replication_type = "GRS"
enable_https_traffic_only = true
min_tls_version = "TLS1_2"
shared_access_key_enabled = true
default_to_oauth_authentication = false
infrastructure_encryption_enabled = false
sas_policy {
expiration_period = "00.02:00:00"
expiration_action = "Log"
}
}# Create the storage account
terraform apply -auto-approve
# Replace the storage account
terraform apply -replace="azurerm_storage_account.main"After you approve the plan, the storage account will be destroyed and recreated, and then will error out as shown above. I don't know why this is happening on replace. The storage account remains tainted in state data, so Terraform will try and replace it on subsequent plans. If you remove the taint manually, then an execution plan comes back with no changes. This seems to be an issue with eventual consistency in the API. I've removed the blob properties and changed |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Is there an existing issue for this?
Community Note
Terraform Version
1.7.0
AzureRM Provider Version
3.88.0
Affected Resource(s)/Data Source(s)
azurerm_storage_account
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
The storage account is created successfully.
Actual Behaviour
The storage account is created in Azure, but errors out in Terraform. Attempts to re-create the resource may fail during planning or apply.
After some additional research, I have determined that the culprit is the combination of the
shared_access_key_enabledargument set totrueandrestore_policyinside theblob_propertiesblock:Removing the
restore_policyblock will allows the storage account to be created successfully.Two other important things to note:
When Terraform tries to re-create the failed storage account, this change is listed in the execution plan:
- share_properties { - retention_policy { - days = 7 -> null } }No share properties have been set in the configuration.
Also, if I create the storage account without the
restore_policyblock and then add the block in afterwards, Terraform is able to modify the storage account without error.It only encounters the issue when creating a new storage account.
Looking through the logs, it seems like after the storage account is created, the azurerm provider is trying to get all the properties of the storage account. When it tries to read the properties of the file services, it is trying to use a SAS token from the storage key. Since that's disabled, the request errors in a 404. No idea why it checks the file services when the
restore_policyis set, but not otherwise.Steps to Reproduce
terraform applyImportant Factoids
No response
References
No response
The text was updated successfully, but these errors were encountered: