Cannot delete Managed environment storage 'XXX' because it's still in use.

[SpyPower]

Please provide us with the following information:

This issue is a: (mark with an x)

• [x] bug report -> please search issues before submitting
• [ ] documentation issue or request
• [ ] regression (a behavior that used to work and stopped in a new release)

Issue description

Hi! I successfully created an Azure Container App, a storage container, a shared folder within the storage container, an Azure container App Environment and connected the Azure Files from the container app Environment to the azure storage container shared folder. The Container App is working like a charm and the container app is successfully mounting the shared folder. I now want to delete this shared folder from azure container app environment but I am unable to do so. The error I get is Failed to update azure files configuration: Cannot delete Managed environment storage 'XXX' because it's still in use.

For testing, I created another Azure Files share from the container app environment with no valid share folder and it was created successfully. After that, I was unable to delete the newly created share from Azure Container Apps Environment. On my example, the share name log Does not exist!

When I deleted the whole Azure Container App Environment, there was no error of the shared still been in use and I was able to continue with the whole environment deletion.

Steps to reproduce

1. Create Storage, create shared folder
2. Create Azure Container App, create Azure Container App Environment
3. From Azure Container App Environment blade, attach the storage.
4. Deploy Azure Container App while attaching the new created volume.
5. Edit Azure Container App and remove the shared volume.
6. Try to delete Azure File share from within Azure Container App Environment. It will fail with error

   Failed to update azure files configuration: Cannot delete Managed environment storage 'XXX' because it's still in use.

Expected behavior [What you expected to happen.] Step 6, queue up the deletion of the share and finally delete the share.

Actual behavior [What actually happened.] Error. No deletion of the share. Screenshots
If applicable, add screenshots to help explain your problem. Disclaimers: I am using a single container, and the traffic is always 100% on the latest container deployed. Using the CLI, I am able to see

    ingress:
      traffic:
      - revisionName: dev-prx--c87yrfx
        weight: 100
      transport: Auto

Additional context

This issue occur in the Portal?

[joaquinvacas]

Same issue here.

Neither the Azure Portal or CLI fixes the problem.

[francescobarbarulo]

Me too. The very bad thing is that there are no checks about the file share existence at creation time.

[hebersgit]

We have the same problem: We created a non-functional entry in the azure-files and used it in a revision in a container-app. Now we corrected this, but because there were 100 inactive (deactivated) revisions maintained, the wrong azure-file entry is still "in use" an cannot be deleted. Either it should be possible to force deletion, or to remove inactive revisions, to get rid of wrong entries.

[reketen]

based on my experience, you CAN delete file share only if you remove all Container Apps that use it.

[joaquinvacas]

based on my experience, you CAN delete file share only if you remove all Container Apps that use it.

Issue here is that there's no app using a file share.

In my case, file share isn't even pointing to a valid storage path...

[kdcllc]

Do we have a workaround for this?

[DrizzlyOwl]

Hello, this is also affecting us, even more so now that an engineer can make this change in the Portal on resources managed by Terraform causing state drift, but because of this error, we're unable to remediate the state via any means

[reketen]

I found another workaround.

1. Deploy a new Container App revision using default hello-word container and make it active.
2. Deactivate all other revisions.
3. Remove storage from Container App Environment
4. Deactivate hello-word revision and activate the revision you need.

[DrizzlyOwl]

I couldn't get it to work using your workaround but completely deleting the container apps and redeploying without the mount worked (but sucks)

[DavyLGinkoia]

I had the same problem. container in production so i can't delete and redeploying them :-(

[Greedygre]

Hi @DavyLGinkoia @DrizzlyOwl @SpyPower @hebersgit

When mount a volume to container, add the volume in both template.containers.volumeMounts, and template.volumes. But when remove the volume in container for containerapp in portal, they only remove it from template.containers.volumeMounts, not remove it from template.volumes.

Workaround:

using az containerapp update --yaml to remove the template.volumes in containerapp: file content as following:

properties:
  template:
    volumes: []

[LyesIsogeo]

I had the same problem. The only solution is to delete the app where there are revisions (even inactive) which was using these file shares.