Why your container mounts vanish into thin air

Technical Briefing | 9/8/2026

You spend all morning debugging a volume mount that refuses to persist inside your pod. Everything looks perfect in the YAML, the storage class exists, and the persistent volume claim is bound. Yet, when you exec into the container, the directory is empty. I have spent enough time digging through mount namespaces to know this usually isn’t a storage provider issue; it’s almost always a race condition or a lifecycle hook hiding in plain sight.

The mount namespace trap

When a pod initializes, the kubelet creates a private mount namespace. If you have an init container that performs some setup on a mount path, the kernel doesn’t automatically propagate those changes to the main application container unless the mount propagation mode is set correctly. Most folks default to private, which means your hard work in the init container effectively disappears the moment the next container starts.

mount --make-shared /var/lib/kubelet/pods/$(uuid)/volumes/kubernetes.io~csi/$(volume)/mount

• Check your mount propagation settings for HostPath or CSI volumes
• Verify the init container lifecycle hasn’t umounted the volume prematurely
• Inspect /proc/self/mountinfo inside the container to see what the kernel actually sees

If you are still pulling your hair out, stop looking at the K8s API logs and start looking at the kernel mount table. Use nsenter to join the pod’s PID 1 namespace and run cat /proc/1/mountinfo. It will tell you the truth about whether your volume is actually mounted or if you are staring at a masked directory created by a secondary overlay layer. It’s tedious, but it saves hours of guessing.