Error on adding a storage share to the Azure storage account

user_10891750 0
Viewed 5385

I'm getting the following error on running terraform apply after adding an azurerm_storage_share.

Error: Error checking for existence of existing Storage Share "fileshare"
(Account "sttestforaddingfileshare" / Resource Group "resources"):
shares.Client#GetProperties: Failure responding to request: StatusCode=403
-- Original Error: autorest/azure: Service returned an error. 
Status=403 Code="AuthorizationFailure" 
Message="This request is not authorized to perform this operation.
\nRequestId:188ae38b-e01a-000b-35b3-a32ea2000000
\nTime:2020-10-16T11:55:16.7337008Z"

I think the reason is most likely that Terraform tries to list existing file shares in the storage account directly accessing the storage account's REST API instead of Azure Resource Manager's REST API.

It failed because there exist firewall rules in place not containing the IP of the host terraform runs on. When I add my laptop's IP to the firewall rules, it works. But it's not the desired behavior.

Do you know any workaround? Any help is appreciated.

My TF configuration is as follows:

provider "azurerm" {
  version     = "= 2.32.0"
  features {}
}
 
resource "azurerm_resource_group" "rg" {
  name     = "resources"
  location = var.location
}

resource "azurerm_virtual_network" "vnet" {
  name                = "vnet"
  location            = var.location
  resource_group_name = azurerm_resource_group.rg.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "snet" {
  name                 = "snet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.0.1.0/24"]
  
  service_endpoints = [ "Microsoft.Storage" ]
}

resource "azurerm_storage_account" "storage" {
  name                     = "sttestforaddingfileshare"
  resource_group_name      = azurerm_resource_group.rg.name

  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"

  network_rules {
    default_action             = "Deny"
    virtual_network_subnet_ids = [ azurerm_subnet.snet.id ]
    bypass = [ "None" ]
  }
}

resource "azurerm_storage_share" "file_share" {
    name                 = "fileshare"
    storage_account_name = azurerm_storage_account.storage.name
    quota                = 100
}
terraform-provider-azure terraform
2 Answers

You can use the azurerm_storage_account_network_rules resource to define the Network Rules and remove the Network Rules block defined directly on the azurerm_storage_account resource.

Also, you can create your file share via using az CLI instead of the separate resource "azurerm_storage_share"

After my validation, with the

PS D:\Terraform> .\terraform.exe -v
Terraform v0.13.4
+ provider registry.terraform.io/hashicorp/azurerm v2.32.0

It worked when terraform apply and terraform destroy.

resource "azurerm_storage_account" "storage" {
  name                     = "nnnstore1"
  resource_group_name      = azurerm_resource_group.rg.name

  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  
provisioner "local-exec" {
    command =<<EOT
    az storage share create `
    --account-name ${azurerm_storage_account.storage.name} `
    --account-key ${azurerm_storage_account.storage.primary_access_key} `
    --name ${var.myshare} `
    --quota 100   
    EOT

    interpreter = [ "Powershell", "-c"]
  }

}
   


resource "azurerm_storage_account_network_rules" "test" {
  resource_group_name  = azurerm_resource_group.rg.name
  storage_account_name = azurerm_storage_account.storage.name

  default_action             = "Deny"
  virtual_network_subnet_ids = [azurerm_subnet.snet.id]
  bypass                     = ["None"]
}

enter image description here

user_98333140

I recently ran into this issue when attempting to create a storage share for a container group. It was pretty much identical code to yours but with the additional container group.

I came across the issue when deploying the stack as new and I bypassed the error by deploying everything but the storage share component and all references to it.

Then when that was completed I introduced the storage share and redeployed without issue.

Crappy work around but its deployed again.

user_98216570
Related