Azure App Service Deployment slot swapping failing

Question

Azure App Service Deployment slot swapping failing

Vijayakumar Ganji 121

Below is our set up:

Azure App Service Web App (PHP 8.3 on Linux OS)
Deployment slot (named as pre-deployment)
Mount Points configured and added in Path mappings of Azure Web app configuration as new mount points. (This is done by storage account & private end point for communication. NOTE: Connectivity is good between mount points and app service, checked by nslookup & tcpping and get proper responses).
Mount point locations are /home/site/wwwroot/myvar , /home/site/wwwroot/mydata
VNET Integration is set up for app to communicate with storage account. NOTE: This is done both for deployment slot & production slot. Even the mount points are configured for deployment slots and the connectivity is good.
Start-up command we are using in configuration of Azure web app is: bash /home/site/wwwroot/azure/startup.sh

After all this set up, we are deploying via Azure DevOps and the swapping is failing from pre-deployment slot to production with below error, any guidance please, as we are stuck with thoughts on what is mistake here:

2025-04-14T15:59:02.362Z ERROR - Container start failed for abc_df67bafe with System.AggregateException, One or more errors occurred. (Docker API responded with status code=InternalServerError, response={"message":"failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/var/LWASFiles/Sites/abct__c5fe/1-xcea848e" to rootfs at "/home/site/wwwroot/myvar": mkdir /mnt/docker/871072.239872/overlay2/bcddbe6b7bd6d2/merged/home/site/wwwroot/myvar: read-only file system: unknown"})InnerException: Docker.DotNet.DockerApiException, Docker API responded with status code=InternalServerError, response={"message":"failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/var/LWASFiles/Sites/abcxz__c5fe/bgt54858e8e" to rootfs at "/home/site/wwwroot/myvar": mkdir /mnt/docker/871072.239872/overlay2/vc3456666864fd6d2/merged/home/site/wwwroot/myvar: read-only file system: unknown"}

Suwarna S Kale 2,906 Reputation points

2025-04-20T02:05:08.3066667+00:00
Hello Vijayakumar Ganji,

Thank you for posting your question in the Microsoft Q&A forum.

The slot swapping failure stems from a fundamental conflict between Azure's containerized OverlayFS and persistent mount points. When the system attempts to remount storage volumes during swaps, the container's read-only root filesystem prevents directory creation, triggering the observed error. This issue commonly occurs when custom mount points intersect with Azure's internal swap mechanics.

The solution involves three key adjustments:

First, explicitly enable persistent storage via WEBSITES_ENABLE_APP_SERVICE_STORAGE to maintain mount integrity.

Second, modify startup scripts to avoid runtime filesystem modifications.

Third, consider overriding default storage behavior with WEBSITES_OVERRIDE_PERSISTENT_STORAGE for critical paths.

These changes align Azure's swap mechanism with persistent storage requirements while maintaining operational stability. For immediate verification, test swaps in preview mode and validate mount point accessibility post-deployment. Persistent issues warrant container log analysis and potential Microsoft Support engagement, particularly when dealing with complex VNET-integrated storage configurations.

Critical Settings:

ini

WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

WEBSITES_OVERRIDE_PERSISTENT_STORAGE=1

If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. Your contribution to the Microsoft Q&A community is highly appreciated.
Vijayakumar Ganji 121 Reputation points

2025-04-20T10:04:35.2733333+00:00
Thank you @Suwarna S Kale , can you please help me understand little bit more about these 2 points.

Second, modify startup scripts to avoid runtime filesystem modifications.

Third, consider overriding default storage behavior with WEBSITES_OVERRIDE_PERSISTENT_STORAGE for critical paths.

If some example or a link to read , thank you
Vijayakumar Ganji 121 Reputation points

2025-04-21T12:31:14+00:00

Also we see below errors:

Unexpected internal error: System.ServiceModel.Web.WebFaultException`1[Microsoft.Web.Hosting.Administration.ErrorEntity]: Bad Request (Fault Detail is equal to Code: BadRequest, ExtendedCode: HttpContext.Current is null object is not present in the request body., Message: 01008).

Swap failed. Details: Cannot swap site slots for site 'AppX' because the 'pre-deployment' slot did not respond to http ping.

1 answer

Your answer

Suwarna S Kale 2,906 Reputation points

2025-04-20T02:05:08.3066667+00:00

Hello Vijayakumar Ganji,

Thank you for posting your question in the Microsoft Q&A forum.

The slot swapping failure stems from a fundamental conflict between Azure's containerized OverlayFS and persistent mount points. When the system attempts to remount storage volumes during swaps, the container's read-only root filesystem prevents directory creation, triggering the observed error. This issue commonly occurs when custom mount points intersect with Azure's internal swap mechanics.

The solution involves three key adjustments:

First, explicitly enable persistent storage via WEBSITES_ENABLE_APP_SERVICE_STORAGE to maintain mount integrity.

Second, modify startup scripts to avoid runtime filesystem modifications.

Third, consider overriding default storage behavior with WEBSITES_OVERRIDE_PERSISTENT_STORAGE for critical paths.

These changes align Azure's swap mechanism with persistent storage requirements while maintaining operational stability. For immediate verification, test swaps in preview mode and validate mount point accessibility post-deployment. Persistent issues warrant container log analysis and potential Microsoft Support engagement, particularly when dealing with complex VNET-integrated storage configurations.

Critical Settings:

ini

WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

WEBSITES_OVERRIDE_PERSISTENT_STORAGE=1

If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. Your contribution to the Microsoft Q&A community is highly appreciated.
Vijayakumar Ganji 121 Reputation points

2025-04-20T10:04:35.2733333+00:00

Thank you @Suwarna S Kale , can you please help me understand little bit more about these 2 points.

Second, modify startup scripts to avoid runtime filesystem modifications.

Third, consider overriding default storage behavior with WEBSITES_OVERRIDE_PERSISTENT_STORAGE for critical paths.

If some example or a link to read , thank you
Vijayakumar Ganji 121 Reputation points

2025-04-21T12:31:14+00:00

Also we see below errors:

Unexpected internal error: System.ServiceModel.Web.WebFaultException`1[Microsoft.Web.Hosting.Administration.ErrorEntity]: Bad Request (Fault Detail is equal to Code: BadRequest, ExtendedCode: HttpContext.Current is null object is not present in the request body., Message: 01008).

Swap failed. Details: Cannot swap site slots for site 'AppX' because the 'pre-deployment' slot did not respond to http ping.

Answer 1

Hi @Vijayakumar Ganji
Apology for the delay response .
The error you're encountering during the swap operation from the pre-deployment slot to production seems to be related to the mounting of the specified directories. The error message indicates that the system is trying to create a directory in a read-only file system, which suggests that there might be an issue with the mount points or the permissions associated with them- Ensure that the mount points (/home/site/wwwroot/myvar and /home/site/wwwroot/mydata) have the correct permissions set for the Azure App Service to access them.

Since you mentioned that the connectivity is good, double-check the configuration of the storage account and the private endpoint to ensure there are no restrictions that might lead to a read-only state.
Ensure that the VNET integration is correctly configured and that there are no network security group (NSG) rules or firewall settings that might be preventing access to the storage account.
The startup command (bash /home/site/wwwroot/azure/startup.sh) should be verified to ensure that it does not inadvertently change the state of the file system or affect the mount points.
Consider using the swap with preview feature to validate the settings and ensure that the application runs correctly with the new configuration before completing the swap.
Troubleshoot swaps Understand what happens during a swap
let me know if you have any further assistances.
If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue.

Share via

Azure App Service Deployment slot swapping failing

1 answer

Your answer