Why your container mounts keep ghosting you after a node reboot

Technical Briefing | 9/8/2026

Most of us treat Kubernetes volume mounts like they are managed by magic. You define a PersistentVolumeClaim, the pod spins up, and your data shows up exactly where it belongs. But then you do a kernel upgrade on a node, the Kubelet restarts, and suddenly your mount points are acting like they were never there or, worse, they are pointing to a stale underlying mount that ignores the new pod’s settings. It is a classic case of mount propagation settings biting back when the environment changes underneath your orchestrator.

The mount namespace is not just a suggestion

The underlying issue is often how your container runtime interacts with the host’s mount namespace. If you have defined your mount propagation as private, the container is essentially living in a bubble. When the host re-mounts a drive or handles a filesystem event during boot, the container has no visibility into that change. I have spent more hours than I care to admit debugging why a read-only filesystem check failed to reflect a changed underlying device because the mount propagation was stuck in a private loop.

findmnt --kernel --output TARGET,PROPAGATION | grep kubelet

• Check your mount propagation settings, specifically moving from private to rslave
• Audit the Kubelet systemd service for shared mount flags if you are using custom CSI drivers
• Watch out for the recursive nature of systemd mounts overriding your manual volume path configuration

If you are running specialized storage like Ceph or raw block devices, stick to using hostPath only as a last resort, and always verify that your mount propagation is explicitly defined in the pod spec. If you set it to rslave, you ensure that the container sees host-level changes to that mount, preventing the ghosting effect. Next time you see a pod stuck in ContainerCreating with a path error, skip the logs and look directly at what the kernel actually thinks is mounted in that namespace.