![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(67.2, 15%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EST%3C/text%3E%3C/svg%3E)
Azure Functions
An Azure service that provides an event-driven serverless compute platform.
Hello sb-toryo-pjt,
Thank you for your very detailed and well-documented question. This is a subtle but critical issue that can be quite confusing when it occurs. The behavior you're seeing, where /home/site/wwwroot is mounted with fuse.zip despite your Function App being configured to run from a Docker container, points to a conflict in the deployment mechanisms.
You are correct in your diagnosis: the fuse.zip mount indicates that the Functions runtime is operating in "Run From Package" mode, effectively ignoring the code within your Docker image [, ].
Why is this happening?
The root cause is almost certainly a lingering configuration from a previous deployment. Even if the WEBSITE_RUN_FROM_PACKAGE application setting is not currently present in your configuration, the underlying App Service platform can retain a "memory" of this deployment method.
This typically happens if the Function App was at any point deployed using a method that enables Run From Package, such as:
Zip Push Deployment: Using Azure CLI (az functionapp deployment source config-zip) or another tool that pushes a zip file directly.
Visual Studio Code Deployment: The Azure Functions extension in VS Code often defaults to using Run From Package mode for deployments.
When a zip deployment is performed with Run From Package enabled (or if the platform defaults to it), it creates a file named packagename.txt in the /home/data/SitePackages directory. This file tells the runtime which zip file to mount. This instruction can persist and take precedence over your Docker container configuration.
How to Fix It and Restore Docker Behavior
To force the Function App to use the code from your Docker container as intended, you need to explicitly clear out the conflicting Run From Package configuration.
Step 1: Clear the Package Setting via Azure CLI
The most reliable way to disable this behavior is to set the WEBSITE_RUN_FROM_PACKAGE setting to 0. This explicitly tells the platform not to use a package file.
Run the following Azure CLI command:
bash
az functionapp config appsettings set --name <your-function-app-name> --resource-group <your-resource-group> --settings WEBSITE_RUN_FROM_PACKAGE="0"
Even if this setting doesn't appear in the portal, setting it to 0 will override any cached or implicit configuration.
Step 2: Restart the Function App
After applying the setting, perform a full restart of your Function App from the Azure portal. This will force the runtime to re-evaluate its startup configuration.
Step 3: Verify the wwwroot Directory
Once the app has restarted, you can connect to the container's shell via the Kudu console (https://<your-function-app-name>.scm.azurewebsites.net/) and run the mount command again. You should no longer see the fuse.zip mount on /home/site/wwwroot. Instead, wwwroot should now reflect the directory structure from your Docker image's WORKDIR.
By explicitly disabling the Run From Package feature, you reset the deployment preference and allow the linuxFxVersion setting to correctly take control, ensuring your app runs the code from your container image as expected.
Best Regards,
Jerald Felix .