Last updated May 2026.
This guide covers how to fix 30-minute Atlantis pod restarts by adding fsGroupChangePolicy: OnRootMismatch to the pod’s security context. This stops kubelet from running recursive chown on large volumes based on community-sourced fixes.
Kubernetes administrators frequently encounter slow pod restarts when dealing with large persistent volumes. The root cause is often kubelet’s default behavior of recursively running chown on all files in a volume when a pod starts. Adding fsGroupChangePolicy: OnRootMismatch to the pod’s security context tells kubelet to only run the permission change when necessary, cutting restart times from 30 minutes to seconds based on community-reported results.
This specific issue is most commonly reported with Atlantis and other tools that maintain large Git repository caches on persistent volumes. The fix is a single-line addition to the pod specification, but the impact on developer workflow is significant. We provide the exact YAML configuration used by the community to resolve this problem.
What the community found
For those running Atlantis in production, the slow restart is a frustrating issue that blocks infrastructure changes during planned restarts. The community consensus is that OnRootMismatch is safe for all standard deployments and should be the default configuration for pods with large, long-lived volumes.
Frequently Asked Questions
Q: Is it safe to set fsGroupChangePolicy to OnRootMismatch in production?
A: Yes. This setting is safe and is the community-recommended standard for pods with large volumes. It only skips the chown when the ownership is already correct, so it never compromises security.
Q: Does this fix apply to all Kubernetes distributions, including EKS and GKE?
A: Yes. The fsGroupChangePolicy field is a standard Kubernetes feature available in all major distributions from version 1.20 onwards, including EKS, GKE, and self-hosted clusters.
Q: What other configurations can cause slow Kubernetes pod startup times?
A: Community reports highlight large ConfigMap or Secret mounts, slow container image pulls, and excessive init container chains as the other most common culprits for slow pod restart times besides the fsGroup issue.
Q: Can this fix be applied across all pods in a namespace automatically?
A: Not natively through Kubernetes, but developers use OPA Gatekeeper or Kyverno admission controllers to enforce this policy on all new pods created within a namespace automatically.