Cannot create a new Linux web app & issues with deployments

Question

Cannot create a new Linux web app & issues with deployments

Riad De Pauw 20

I have an issue creating a linux web app, it doesn't let me create a new one after deleting it a few times before. Here's the correlation ID: 7e38da1b-8faf-4124-98d3-e15286fe6e9f

I'm using Azure for Students subscription, so we have to use the free plan as well. The issue I'm having at the moment that was even before this problem of creating a new web app, is that I cannot seem to deploy my changes from github to my azure web app. I would always get a 409 error A.K.A conflict, it would always say that there would be already a deployment in progress but that is not the case? Even in the deployment center where you can find the logs within Azure, nothing is being shown. image_2025-03-02_221902027

Here's the operation details regarding the deployment of the linux web app I'm trying to create:

{
    "status": "Failed",
    "error": {
        "code": "ServiceUnavailable",
        "message": "Storage access failed. Storage access failure - please retry later. Please delete and recreate backup schedule to mitigate.",
        "details": [
            {
                "message": "Storage access failed. Storage access failure - please retry later. Please delete and recreate backup schedule to mitigate."
            },
            {
                "code": "ServiceUnavailable"
            },
            {}
        ]
    }
}

Is there a rate limit within my account or is it something else?

Thanks in advance!

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

Answer accepted by question author

Laxman Reddy Revuri 5,475 Microsoft External Staff Moderator

Hi @Riad De Pauw
If you've deleted a web app multiple times, you might experience a temporary delay when trying to recreate it. This is because Azure enforces certain restrictions on resource creation, especially for subscriptions like Azure for Students, which have stricter limits compared to standard plans.A 409-conflict error during deployment usually means another deployment is already in progress. If you don’t see any logs in the deployment center, it’s worth checking for any ongoing operations that might be blocking the process. Some subscription plans come with limited resources, which can sometimes lead to throttling or delays in deployment.

Trying to create the web app again after waiting – assuming it would work now.

Checking for existing deployments that might have hit a wall.

Reviewing quotas and limits set on the Azure subscription to confirm using resources allocated within limits.
Please accept as "Yes" if the answer provided is useful, so that you can help others in the community looking for remediation for similar issues.

Riad De Pauw 20 Reputation points

2025-03-04T15:27:41.52+00:00

Yes this was pretty much it. I also have a front-end app, and in that app there we're zip files that were using over the limit of storage we have. I fixed it by deleting them manually through Bash, it's all good now.

1 additional answer

Riad De Pauw 20 Reputation points

2025-03-04T15:27:41.52+00:00

Yes this was pretty much it. I also have a front-end app, and in that app there we're zip files that were using over the limit of storage we have. I fixed it by deleting them manually through Bash, it's all good now.

Answer 1

I hit the exact same error today when creating a new Linux web app (portal and az webapp create both failed):

Storage access failed. Storage access failure - please retry later. Please delete and recreate backup schedule to mitigate.

The message is misleading. None of my apps had a backup configured, and retrying didn't help. The real cause was that the App Service plan's shared file storage was almost full, filled up by a different app on the same plan. That matches the poster's own finding above (large zip files in another app).

All apps on a plan share one file-system quota (10 GB on Basic, for example), so one app can block creating any new app on that plan.

1. Check usage per app on the plan (Cloud Shell; repeat for each app on the plan):

$id = az webapp show -n <app-name> -g <resource-group> --query id -o tsv

az rest --method get --url "https://management.azure.com$id/usages?api-version=2023-12-01" --query "value[?name.value=='FileSystemStorage'].{used:currentValue, limit:limit, unit:unit}" -o table

In my case one app was using 9.4 GB of the 10 GB limit.

2. Find what's taking the space (in that app: Advanced Tools > Go > SSH/Bash):

du -xm --max-depth=1 /home

For me it was an application log folder under /home that the app appended to forever, with no rotation. Common culprits are app-written logs and data, /home/LogFiles, and old deployment zips.

3. Free the space. If the data matters, compress it first. /tmp in the container is local disk and usually has plenty of room, but it is not persistent, so move the archive back under /home afterwards:

mkdir -p /tmp/arch

gzip -c /home/<folder>/<big-file> > /tmp/arch/<big-file>.gz

gzip -t /tmp/arch/*.gz

# then truncate or replace the big file, and:

mkdir -p /home/<folder>-archive && mv /tmp/arch/*.gz /home/<folder>-archive/

My 9.4 GB of logs compressed to about 430 MB.

4. Create the app again. Once the plan was back to about 1 GB used, az webapp create succeeded right away.

5. Fix the app that filled the disk (log rotation or retention), or the plan will fill up again.

Hope this saves someone else the time.