Volume Mount Failure¶
Symptom¶
The volume attaches, but the container never gets a usable mount path. Pods often remain in ContainerCreating, or the application starts and then fails because the expected files are missing or inaccessible.
Possible Causes¶
- Kubelet mount failures on the node.
- Filesystem corruption or incompatible filesystem expectations.
- Azure Files SMB secrets, ACLs, or role assignments are wrong.
- The workload expects a different path, protocol, or permissions model than the mounted volume provides.
Diagnosis Steps¶
flowchart TD
A[Mount fails] --> B[Inspect pod events and mount path]
B --> C[Identify storage family and protocol]
C --> D[Check permissions secrets and identity path]
D --> E[Validate app can read expected files] -
Inspect pod events for mount failures.
-
Inspect the PVC and StorageClass to confirm protocol and mount options.
-
For Azure Files SMB, verify secrets or identity path.
-
Validate the application path inside a healthy test pod where possible.
Resolution¶
- Fix the secret, SMB role assignment, or workload-identity path for Azure Files SMB mounts.
- Correct mount options or protocol mismatches.
- Repair the application path assumptions so the container reads the actual mounted directory.
- For suspected filesystem issues on block storage, restore from snapshot or rebuild the pod against a validated recovery point.
Prevention¶
- Standardize mount paths and storage-class definitions per workload family.
- Use validation pods to test storage classes before rollout.
- Prefer least-privilege identity models over long-lived secrets where supported.