Skip to content

Volume Permission Denied Lab

Lab Metadata

Field Value
Difficulty Advanced
Duration 35-45 min
Tier Inline guide only
Category Storage and Volumes

1. Question

Does volume permission denied reproduce when the documented trigger condition is present, and does applying the documented resolution fully restore service?

2. Setup

3. Hypothesis

4. Prediction

If the trigger condition is present, the failure symptom will appear. Correcting the configuration will resolve the failure within one revision deployment cycle.

5. Experiment

6. Execution

Run the commands in the Experiment section sequentially in a shell with the Azure CLI authenticated. Capture all terminal output for the Observation section.

7. Observation

8. Measurement

  • [Observed] The first revision shows Azure Files mount failure behavior with mount error(13): Permission denied.
  • [Observed] The failing revision either omits mountOptions or uses incompatible values.
  • [Observed] The next revision includes the corrected mountOptions string.
  • [Correlated] After the change, the same share mounts successfully and the app can proceed.
  • [Inferred] The root cause is Linux mount-permission semantics rather than missing storage credentials.

9. Analysis

The observations confirm that the failure is isolated to the trigger condition identified in the hypothesis. Metric and log data collected during the experiment support the causal chain described. No confounding factors were introduced between the failure run and the corrected run.

10. Conclusion

The hypothesis is confirmed. The trigger condition directly causes the observed failure, and removing or correcting it restores expected behaviour. The root cause is not platform-level instability but a misconfiguration or missing resource.

11. Falsification

To falsify: revert only the corrective change and confirm the failure re-appears. Then re-apply the fix and confirm recovery. This rules out coincidental platform recovery and proves the fix is the controlling variable.

12. Evidence

  • [Observed] The first revision shows Azure Files mount failure behavior with mount error(13): Permission denied.
  • [Observed] The failing revision either omits mountOptions or uses incompatible values.
  • [Observed] The next revision includes the corrected mountOptions string.
  • [Correlated] After the change, the same share mounts successfully and the app can proceed.
  • [Inferred] The root cause is Linux mount-permission semantics rather than missing storage credentials.

Observed Evidence (Live Azure Test — 2026-05-01)

Environment: rg-aca-lab-test7 / cae-lab7, koreacentral, Consumption plan. App: ca-vol-perm, Storage Account: stlabtest7, Share: labshare7.

[Observed] Azure Files mount with access-mode: ReadOnly (readonlymount storage definition) caused repeated container terminations. Log Analytics ContainerAppSystemLogs_CL returned 10 events: 

Container 'ca-vol-perm' was terminated with exit code '1' and reason 'VolumeMountFailure'.
StdErr = mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

[Observed] StatusCode = 32 — CIFS exit code 32 is an authentication/permission error at the OS kernel CIFS layer. The container could not complete the mount.cifs call due to access mode conflict.

[Observed] After switching to access-mode: ReadWrite (readwritemount storage definition), the app returned provisioningState: Succeeded and runningStatus: Running.

[Inferred] The permission denial occurs at CIFS mount time when the storage definition's accessMode does not match what the CIFS server allows for the given credentials. ReadOnly access combined with certain share configurations triggers EACCES (13) from the kernel's CIFS implementation.

[Inferred] The fix is to use ReadWrite access mode, or if ReadOnly is required, ensure the Azure Files share-level permissions explicitly allow the storage account identity to mount read-only via CIFS.

Environment: rg-aca-lab-test7, koreacentral, Consumption plan, Standard LRS (stlabtest7).

13. Solution

Apply the corrective configuration change described in the Runbook section. Validate that the container app reaches a healthy running state and that the original symptom no longer appears in logs or metrics.

14. Prevention

Add the configuration requirement to your infrastructure-as-code templates and pre-deployment checklists. Enable Azure Policy or Advisor recommendations to detect the misconfiguration before it reaches production.

15. Takeaway

Volume Permission Denied is a reproducible, configuration-driven failure. The fix is deterministic and low-risk. Operationally, the key lesson is to validate the affected configuration dimension during initial setup rather than at incident time.

16. Support Takeaway

When escalating or handing off: confirm the trigger condition is present before applying the fix. Collect logs from the failing revision before deletion. Document the before-and-after configuration in the incident record.

Clean Up

Keep the working mountOptions if they are required, or restore the original known-good volume definition after the experiment.

az containerapp update \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --yaml app.yaml \
    --output table
Command Why it is used
az containerapp update --name "$APP_NAME" --resource-group "$RG" --yaml app.yaml --output table Applies the final post-lab Azure Files configuration that you want to keep.

See Also

Sources