Azure fileshare backup resource failing with message - storage account not registered with vault , but its already registered

[KannappanSomu]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

terraform 0.14.7
tried with both azure provider 2.53 and 2.46.1

Affected Resource(s)

• azurerm_backup_protected_file_share

Terraform Configuration Files

resource "azurerm_recovery_services_vault" "recovery-vault-prod" {
  count = var.environment == "dev" ? 0 : 1 
  name                = "kap-recovery-vault-prod"
  location            = "westeurope"
  resource_group_name = var.resource_group_name
  sku                 = "Standard"
}

resource "azurerm_backup_container_storage_account" "kap-protection-prod" {
  count = var.environment == "dev" ? 0 : 1 
  resource_group_name = var.resource_group_name
  recovery_vault_name = azurerm_recovery_services_vault.recovery-vault-prod[count.index].name
  storage_account_id  = module.storage-account-kapacitors.storage_account_id
}
resource "azurerm_backup_container_storage_account" "etcd-protection-prod" {
  count = var.environment == "dev" ? 0 : 1 
  resource_group_name = var.resource_group_name
  recovery_vault_name = azurerm_recovery_services_vault.recovery-vault-prod[count.index].name
  storage_account_id  = module.storage-account-etcd-chronograf.storage_account_id
}
resource "azurerm_backup_policy_file_share" "kap-recovery-prod" {
  count = var.environment == "dev" ? 0 : 1 
  name                = "kap-recovery-prod-vault-policy"
  resource_group_name = var.resource_group_name
  recovery_vault_name = azurerm_recovery_services_vault.recovery-vault-prod[count.index].name

  backup {
    frequency = "Daily"
    time      = "23:00"
  }

  retention_daily {
    count = 10
  }
}



--------------------

resource "azurerm_backup_protected_file_share" "share1" {
  resource_group_name       = var.resource_group_name
  recovery_vault_name       = var.recovery_vault_name
  source_storage_account_id = var.source_storage_account_id
  source_file_share_name    = azurerm_storage_share.file_share.name
  backup_policy_id          = var.backup_policy_id
}


----------------------

Debug Output

Panic Output

2021-04-01T00:09:55.1007600Z Error: [ERROR] fileshare XXXXXXXX not found in protectable or protected fileshares, make sure Storage Account "kapdatadev" is registered with Recovery Service Vault "kap-recovery-vault" (Resource Group "XXXXXXX")
2021-04-01T00:09:55.1008458Z
2021-04-01T00:09:55.1008991Z on modules\azure-storage-share\main.tf line 13, in resource "azurerm_backup_protected_file_share" "share1":
2021-04-01T00:09:55.1009601Z 13: resource "azurerm_backup_protected_file_share" "share1" {
2021-04-01T00:09:55.1009823Z

Expected Behaviour

the storage account is already registerd with recovery vault & so it should create backup of fileshare

Actual Behaviour

2021-04-01T00:09:55.1007600Z Error: [ERROR] fileshare XXXXX not found in protectable or protected fileshares, make sure Storage Account "kapdatadev" is registered with Recovery Service Vault "kap-recovery-vault" (Resource Group "XXXXXXXX")
2021-04-01T00:09:55.1008458Z
2021-04-01T00:09:55.1008991Z on modules\azure-storage-share\main.tf line 13, in resource "azurerm_backup_protected_file_share" "share1":
2021-04-01T00:09:55.1009601Z 13: resource "azurerm_backup_protected_file_share" "share1" {
2021-04-01T00:09:55.1009823Z

Steps to Reproduce

1. terraform apply

Comments:

I believe this is a bug in terraform after some recent changes in flishare API. Its working with following workaround

workaround :

Enable back up manually for fileshare &
then stop the backup again
and rerun terraform apply step

[KannappanSomu]

failed with both terraform providers 2.53 , 2.46.1

[KannappanSomu]

any update on this

[otabut]

👍

[geekzter]

The same HCL fails under certain conditions only:

• Creating 1 protected item: SUCCESS
• Creating 2 protected items: SUCCESS
• Adding a protected item to a pre-existing one: ERROR (same as above)

resource azurerm_backup_protected_file_share minecraft_data {
  resource_group_name          = azurerm_resource_group.minecraft.name
  recovery_vault_name          = azurerm_recovery_services_vault.backup.0.name
  source_storage_account_id    = azurerm_storage_account.minecraft.id
  source_file_share_name       = module.minecraft[each.key].container_data_share_name
  backup_policy_id             = azurerm_backup_policy_file_share.nightly.0.id

  depends_on                   = [azurerm_backup_container_storage_account.minecraft]

  for_each                     = var.enable_backup ? toset(keys(var.minecraft_config)) : []
}

terraform -v
Terraform v1.0.1
on darwin_amd64
+ provider registry.terraform.io/hashicorp/azuread v1.6.0
+ provider registry.terraform.io/hashicorp/azurerm v2.65.0
+ provider registry.terraform.io/hashicorp/http v2.1.0
+ provider registry.terraform.io/hashicorp/null v3.1.0
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/time v0.7.1

[arock76]

Any update on this one?

I am experiencing the same error.
Error: [ERROR] fileshare 'XXXXXXXX' not found in protectable or protected fileshares, make sure Storage Account "XXXXXXX" is registered with Recovery Service Vault "XXXXXXXX" (Resource Group "XXXXXXXXXX")

terraform -v
Terraform v0.14.5

• provider registry.terraform.io/hashicorp/azuread v1.6.0
• provider registry.terraform.io/hashicorp/azurerm v2.67.0

I found another workaround is to go into the recovery services vault and go through the steps to add the file share manually. Once the select file shares screen refreshes with the new share you can cancel out and run successfully in Terraform.

[G0PINATH-WW]

Another workaround is to use deploy this as an ARM deployment.

resource "azurerm_resource_group_template_deployment" "fs" {

name = "replacedeploymentname"
resource_group_name = "replaceresourcegroupname"

template_content = file("${path.module}/arm/arm.json")

parameters_content = jsonencode({
"existingResourceGroupName" = {
value = "replaceresourcegroupname" #RG where vault exists
}
"existingStorageAccountName" = {
value = "replacestorageaccountname"
}
"existingFileShareName" = {
value = "replacefilesharename"
}
"vaultName" = {
value = "replacevaultname"
}
"policyName" = {
value = "replacevaultpolicyname"
}
})

deployment_mode = "Incremental"
#never set this to complete.

}

contents of ./arm/arm.json is as follows

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"existingResourceGroupName": {
"type": "String",
"defaultValue": "[resourceGroup().name]",
"metadata": {
"description": "Name of the existing Resource Group in which the existing Storage Account is present."
}
},
"existingStorageAccountName": {
"type": "String",
"metadata": {
"description": "Name of the existing Storage Account in which the existing File Share to be protected is present."
}
},
"existingFileShareName": {
"type": "String",
"metadata": {
"description": "Name of the existing File Share to be protected."
}
},
"policyName": {
"type": "String"
},
"vaultName": {
"type": "String",
"metadata": {
"description": "Name of the Recovery Services Vault. (Should have the same location as the Storage Account containing the File Share to be protected in case of an existing Recovery Services Vault)."
}
}
},
"variables": {
"backupFabric": "Azure"
},
"resources": [{
"type": "Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItems",
"apiVersion": "2020-02-02",
"name": "[concat(parameters('vaultName'), '/', variables('backupFabric'), '/storagecontainer;Storage;', parameters('existingResourceGroupName'), ';', parameters('existingStorageAccountName'), '/AzureFileShare;', parameters('existingFileShareName'))]",
"dependsOn": [],
"properties": {
"protectedItemType": "AzureFileShareProtectedItem",
"sourceResourceId": "[resourceId(parameters('existingResourceGroupName'), 'Microsoft.Storage/storageAccounts', parameters('existingStorageAccountName'))]",
"policyId": "[resourceId('Microsoft.RecoveryServices/vaults/backupPolicies', parameters('vaultName'), parameters('policyName'))]",
"isInlineInquiry": true
}
}]
}

[sinbai]

when using the azurerm_backup_container_storage_account resource to register storage account with the recovery service vault, depends_on should be used explicitly declare the dependency to make sure the registration is completed before creating the azurerm_backup_protected_file_share like this:

---

resource "azurerm_backup_protected_file_share" "share1" {
resource_group_name = var.resource_group_name
recovery_vault_name = var.recovery_vault_name
source_storage_account_id = var.source_storage_account_id
source_file_share_name = azurerm_storage_share.file_share.name
backup_policy_id = var.backup_policy_id
depends_on = [azurerm_backup_container_storage_account.etcd-protection-prod]
}

---

Try adding the depends_on to verify this issue is fixed, please let me know if this issue persists.

[G0PINATH-WW]

@sinbai This is NOT a depends on problem, below are the scenarios that I have been able to repro this issue

Existing infra
Existing storage account - storageexample01 - this will contain shares that will be used by multiple teams/apps.
Existing RSV - rsvexample01 - storageexample01 is already registered on this RSV.
From the portal I can create a share called share01 and enable backup on rsvexample01

If I used terraform code to create share02 and share03(storageexample01) and then enable backup for these 2 shares on this RSV then the above error is returned.
If I navigate to the RSV -> Backup Items -> and then select the storage account and scan the file shares - share02 and share03 will be scanned by RSV. At this point, if I cancel that wizard and rerun the terraform code, it works just fine.

New Infra
If you follow the full example and deploy RSV, Storage account and file shares, it works perfectly fine the first time.
If you update this code to include another share deployment on the same storage account and enable backup for this new file share, you can will encounter the error. If you scan the storage account via RSV for new shares then the code will work.

[sinbai]

@KannappanSomu I can reproduce this issue based on your TF config, and verified it can be fixed after adding depends_on. Could you help verify that this issue is resolved on your side when the depends_on is added in tf config?

[KannappanSomu]

sure , will update you soon .

[github-actions]

This functionality has been released in v2.86.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

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.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.