azurerm_logic_app_standard doesn't create WEBSITE_CONTENTSHARE share

[hichamveo]

Is there an existing issue for this?

• I have searched the existing issues

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

Terraform Version

1.9.0

AzureRM Provider Version

3.101.0

Affected Resource(s)/Data Source(s)

azurerm_logic_app_standard

Terraform Configuration Files

N/A

Debug Output/Panic Output

N/A

Expected Behaviour

a share should be created in the storage account used by logic apps with the name : logicappname-content

Actual Behaviour

the share is not created

Steps to Reproduce

No response

Important Factoids

No response

References

No response

[ziyeqf]

Hi @hichamveo, thanks for reporting.

Could you please provide more detail or the configuration? I tried to create a azurerm_logic_app_standard, and the file share was created.

When storage_account_share_name is specified, its value will be used as the name of file share, otherwise, the {logic_app_name}-content will be the name.

Thanks

[hichamveo]

Hi @ziyeqf ,

for information, with the same code, I was able to provision my LA successfully 2 months ago, now facing this issue when I'm trying to provision new environments.

here is TF resource declaration:

`resource "azurerm_logic_app_standard" "la_standard" {
depends_on = [
azapi_resource.blob_con,
azapi_resource.sb_con
]
name = someName
location = var.location
resource_group_name = var.resource_group_name
app_service_plan_id = azurerm_app_service_plan.app_service_plan.id
virtual_network_subnet_id = mysubnet_id
storage_account_name = var.storage_account_name
storage_account_access_key = data.azurerm_storage_account.backend.primary_access_key
version = var.runtime_function_version
https_only = true

app_settings = merge(
{
"FUNCTIONS_WORKER_RUNTIME" = var.functions_worker_runtime
"WEBSITE_NODE_DEFAULT_VERSION" = var.website_node_default_version
"APPLICATIONINSIGHTS_CONNECTION_STRING" = module.application_insights.ai_connection_string
"WORKFLOWS_SUBSCRIPTION_ID" = data.azurerm_subscription.current.subscription_id
"WORKFLOWS_RESOURCEGROUP" = var.resource_group_name
"azureTables_tableStorageEndpoint" = var.at_endpoint
"serviceBus_fullyQualifiedNamespace" = var.sb_fq_namespace
"AzureBlob_blobStorageEndpoint" = var.sa_endpoint
"WEBSITE_CONTENTOVERVNET" = var.content_over_vnet
},
{for index, s in var.blob_connections : s.runtimeUrl => jsondecode(azapi_resource.blob_con[index].output).properties.connectionRuntimeUrl},
{for index, s in var.sb_connections : s.runtimeUrl => jsondecode(azapi_resource.sb_con[index].output).properties.connectionRuntimeUrl},
{for index, s in var.eg_connections : s.runtimeUrl => jsondecode(azapi_resource.eg_con[index].output).properties.connectionRuntimeUrl}
)

site_config {
http2_enabled = true
vnet_route_all_enabled = true
}

identity {
type = "SystemAssigned"
}

lifecycle {
ignore_changes = [
app_settings,
]
}

}`

there is no access restriction on the Storage account, the share is created successfully when I create a LA Standard manually on the same Storage account.

[ziyeqf]

Hi @hichamveo, thanks for providing config.

The config seems correct, could you please try the following steps and provide the log file? (the log file may contain credential info like subscription ID, please remove them before uploading)

1. enable debug logging by specifying environment variable TF_LOG=DEBUG and TF_LOG_PATH=<log file path> documents
2. apply and upload the log file
3. If the file share still not created, specifying storage_account_share_name, apply and upload the log file too.

Thanks

[hichamveo]

unfortunately I will not be able to generate debug file, the deploy agents are hosted on scale set vms destroyed after the deployment and locally not have needed permissions. will try a deployment by specifying the share_name and I will share the findings