Azure Function App (Linux) Permission Denied

Question

Last week I deployed a new function app from Visual Studio to Azure running on a Flex Consumption Plan (Linux).

It worked.

Today I needed to update the app, so I tried to deploy again, and after having to delete my publish profile, logout of visual studio, login again and create a new publish profile, I managed to deploy it.

However, it fails to start.

In Application Insights I find an exception:

"An error occurred trying to start process '/home/site/wwwroot/MyFunction' with working directory '/home/site/wwwroot'. Permission denied"

I have checked everything suggested by the AI trouble shooter and can't find any issues.

AI suggests I need to log onto the Kudo console and check the executable has execute permission.

I can't login to the Kudo console as it just displays:

{ "message":"Kudu WebAPI."}

AI suggests this is because the function app is not running, and I need to fix that before I can get to the console.

How do I fix permission issues on the deployed function app if I can't get to the Kudo console?

Answer 1

Hello John Hynes,

It looks like your Function App on Linux can’t start because the host is trying to execute your function binary (/home/site/wwwroot/MyFunction) but it doesn’t have the “x” bit set—and since you’re on a Flex Consumption (Linux) plan with run-from-package enabled, you can’t just jump into Kudu and chmod it (the file system is read-only when run-from-package is on, and your app isn’t running so the normal Kudu UI/API isn’t available).

Here’s how to get unstuck:

1. Confirm whether you’re running from package • In the Azure Portal go to Configuration > Application settings and look for WEBSITE_RUN_FROM_PACKAGE. • If it’s set to “1” (or you see a ZIP URL in that setting), the app content is mounted read-only.
2. If you are run-from-package, you must set the execute bit before zipping and deploying a. On a Linux or WSL box, in your function project folder run: • chmod +x MyFunction (or whatever your handler binary is called) b. Recreate your ZIP so it preserves Unix permissions: • zip -r --symlinks functionapp.zip * c. Deploy with ZIP deploy (this ensures the package you build is exactly what lands on the host): • func azure functionapp publish <YourAppName> --zip path/to/functionapp.zip That way the mounted package already has the correct exec bit and the Functions host can start it.
3. If you’d rather tweak permissions on the server side, you can temporarily disable run-from-package a. Set WEBSITE_RUN_FROM_PACKAGE to 0 (or remove it), save and let a redeploy extract files to a writeable wwwroot. b. Once the app is up you can use the Portal’s SSH (under Development Tools) or the Kudu Debug Console to run chmod +x MyFunction. c. Re-enable run-from-package if you want the performance/consistency benefits of mounted packages.
4. Double-check your startup command (if you’ve overridden it) • If you’re using a custom handler, make sure your customHandler.json points to the correct executable and that it’s located in wwwroot with exec permissions.

Hope that helps get your Linux function back online! If it still fails, let us know:

• Are you using a custom handler or a built-in runtime (C#, Node, etc.)?

• How are you publishing (ZIP deploy, VS publish profile, CI/CD)?

• What do you have set for WEBSITE_RUN_FROM_PACKAGE and any custom startup command?

—Reference—

• Adding/Creating functions from source control (run-from-package makes wwwroot read-only)

https://learn.microsoft.com/azure/azure-functions/run-functions-from-deployment-package

• SSH into your Linux Function App (bypasses Kudu when app isn’t running)

https://learn.microsoft.com/azure/app-service/configure-language-python#ssh-support

• Permission Denied Error in App Service (exec-bit reminders and allowed paths)

https://learn.microsoft.com/answers/a/12281919?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Please accept as answer and do a Thumbs-up to upvote this response if you are satisfied with the community help. Your upvote will be beneficial for the community users facing similar issues.

Answer 2

The failure is a runtime issue in the deployed app, not a deployment problem. The key is to diagnose and fix the runtime configuration and file access, rather than relying on Kudu.

Use these steps that don’t depend on Kudu access:

1. Restart and run platform diagnostics
   1. In the Azure portal, open the Function App.
   2. Manually restart the function app.
   3. Go to Diagnose and solve problems and run Azure Function App Diagnostics. This workflow checks:
      • Startup issues and recent deployments
      • Runtime and language version validity
      • Configuration issues (mandatory app settings, Key Vault/Managed Identity, SyncTriggers, host name collisions)
      • Hosting plan setup and execution health
   4. Use the diagnostic findings to correct any configuration or runtime version issues it reports.
2. Verify storage and network access A missing or inaccessible storage account can prevent the runtime from starting and cause file access problems.
   1. Confirm the storage account configured for the Function App is reachable and that storage connection strings are correct.
   2. If the app uses VNet integration, NSGs, or storage firewalls, run the Connectivity/Network Troubleshooter from Diagnose and solve problems. This tool validates:
      • DNS resolution
      • Storage and Key Vault access
      • Outbound restrictions (VNet, NSG, firewalls)
   3. Fix any reported issues (for example, misconfigured VNet integration or blocked storage endpoints).
3. Check runtime and deployment mode
   1. Confirm the Function runtime version is supported and correctly configured (for Linux Flex Consumption, ensure the runtime and language version match what was used when it previously worked).
   2. If using WEBSITE_RUN_FROM_PACKAGE (Run From Package / Zip Deploy), remember that /home/site/wwwroot is mounted read-only and the runtime executes from the package. If the package or its SAS is invalid or inaccessible, the runtime can fail to start.
   3. Redeploy from Visual Studio to regenerate the package and configuration, ensuring the deployment completes successfully.
4. Use Application Insights for detailed errors
   1. In Application Insights, review:
      • exceptions for runtime exceptions
      • traces filtered to LogLevel == "Error"
   2. Use the full stack trace to identify whether the permission error is coming from:
      • The host trying to execute a file that isn’t marked executable in the package
      • Code that assumes local paths or writes to disallowed locations
5. Fix invalid path or file assumptions in code Common causes of permission errors in Linux Function Apps include:
   • Attempting to execute a file or script that isn’t part of the deployed package or isn’t executable in the package.
   • Writing to paths that are not allowed or are read-only when running from package. Ensure the function:
   • Uses only supported write locations (for Linux, under /home where allowed) and doesn’t rely on local development paths.
   • Does not attempt to start processes or binaries that aren’t present or executable in the deployment package.
6. If Kudu remains unavailable Kudu is not available for Linux Flex Consumption plans, so rely on:
   • Azure Function App Diagnostics
   • Network/Connectivity Troubleshooter
   • Application Insights logs
   • Redeploying the app with corrected code and configuration

By combining a fresh deployment with diagnostics (Function App Diagnostics, network validator, and Application Insights), the permission issue can be isolated and resolved without needing Kudu.

---

References:

• Resolve common runtime issues after deployment
• Resolve "Function App Down or Reporting Errors" issues