☸️ Kubernetes Error Guide: 'no such file /var/run/secrets/.../token' ServiceAccount Token Not Mounted

Exact Error Message

error: open /var/run/secrets/kubernetes.io/serviceaccount/token: no such file or directory

In-cluster client libraries report the same root cause in different words, for example unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined or serviceaccounts "default" is forbidden after the token is absent and the pod falls back to anonymous access.

Overview

Every pod that talks to the Kubernetes API from inside the cluster authenticates with a ServiceAccount token. By default the kubelet projects that token, along with the cluster CA and namespace, into each container at /var/run/secrets/kubernetes.io/serviceaccount/. In-cluster client libraries read the token file automatically to build their API configuration.

This error means the token file is not there. Either the pod was told not to mount it (automountServiceAccountToken: false), the projected-token volume was removed or overridden, or the ServiceAccount the pod references does not exist. Without the token, any in-cluster API call is unauthenticated and fails, and code that opens the file path directly errors with no such file or directory.

Symptoms

• An application that calls the Kubernetes API logs no such file or directory for the token path on startup.
• kubectl exec into the pod shows the serviceaccount directory missing or lacking a token file.
• API calls from the pod return Unauthorized or forbidden: User "system:anonymous".
• The pod otherwise starts and runs; only its API access is broken.

Common Root Causes

1. automountServiceAccountToken is set to false

Setting this to false on the pod spec or on the ServiceAccount stops the kubelet from mounting the token, so the file never appears.

2. The referenced ServiceAccount does not exist

If serviceAccountName points at a name that is not in the namespace, the kubelet cannot project a token for it.

3. A volume or volumeMount overrides the projected path

Mounting an emptyDir or another volume at /var/run/secrets/kubernetes.io/serviceaccount shadows the automatically injected token volume.

4. Security tooling stripped the token

Admission controllers, PodSecurity policies, or hardening tools sometimes remove the projected token volume to reduce credential exposure.

5. Expired bound token not refreshed

With bound service account tokens, a container that caches the token but never re-reads the rotating file may see auth failures even when the file exists; a genuinely missing file is the stricter case.

Diagnostic Workflow

Step 1: Check whether the token file exists in the pod

kubectl exec <pod> -- ls -l /var/run/secrets/kubernetes.io/serviceaccount/

A missing token, ca.crt, or namespace file confirms the projection is absent.

Step 2: Inspect the pod’s automount setting

kubectl get pod <pod> -o jsonpath='{.spec.automountServiceAccountToken}'

An explicit false here (or on the ServiceAccount) is the direct cause.

Step 3: Confirm the ServiceAccount exists

kubectl get serviceaccount <name> -n <namespace>

If it is missing, the pod references a name that was never created.

Step 4: Look for a volume overriding the token path

kubectl get pod <pod> -o jsonpath='{.spec.volumes}' | tr ',' '\n'

Check for any volume mounted at the serviceaccount path.

Step 5: Verify the token actually authenticates

kubectl exec <pod> -- sh -c \
  'curl -s --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
   -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
   https://kubernetes.default.svc/api'

Step-by-Step Resolution

1. Re-enable automounting where the workload genuinely needs API access. Set it on the pod spec so it takes precedence:

spec:
  automountServiceAccountToken: true
  serviceAccountName: my-app

2. Create the ServiceAccount if it is missing:

kubectl create serviceaccount my-app -n my-namespace

Then reference it with serviceAccountName: my-app and restart the pod.

3. Remove any overriding volume that shadows /var/run/secrets/kubernetes.io/serviceaccount. Delete the conflicting volumeMount so the kubelet’s projected volume is used.

4. If you need a token but the platform strips the default, project one explicitly:

      volumes:
        - name: sa-token
          projected:
            sources:
              - serviceAccountToken:
                  path: token
                  expirationSeconds: 3600
                  audience: api

Mount it and point your client at that path.

5. Grant the ServiceAccount the RBAC it needs so that once the token is present, calls are authorized:

kubectl create rolebinding my-app-view \
  --clusterrole=view --serviceaccount=my-namespace:my-app -n my-namespace

6. Restart and confirm the token is mounted and working:

kubectl rollout restart deployment <deployment> -n my-namespace
kubectl exec <new-pod> -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | head -c 20

Seeing token bytes confirms the projection is restored.

Prevention

• Only set automountServiceAccountToken: false on workloads that never call the API, and be explicit about which ones do need it.
• Give each application its own ServiceAccount with least-privilege RBAC rather than relying on default.
• Avoid mounting volumes at the reserved serviceaccount path; pick a different mount point for app data.
• Use bound, audience-scoped projected tokens with a sensible expirationSeconds and ensure clients re-read the rotating file.
• Add a startup check in your app that verifies the token path exists and fails fast with a clear message.

Related Errors

• serviceaccounts "default" is forbidden: User "system:anonymous" — the pod fell back to anonymous because no token was mounted.
• Unauthorized from in-cluster API calls — a present but invalid or expired token.
• pods "x" is forbidden: ... cannot get resource — the token authenticated but lacks RBAC permissions.
• unable to load in-cluster configuration — the client library could not find the token or the service env vars.

Frequently Asked Questions

Where should the token file be? In-cluster it lives at /var/run/secrets/kubernetes.io/serviceaccount/token, alongside ca.crt and namespace. If that file is missing, the kubelet did not project the token for this pod.

Why would automountServiceAccountToken be false? It is a hardening choice to avoid handing API credentials to workloads that do not need them. Set it back to true only for pods that genuinely call the API.

Does using a custom ServiceAccount fix this? It helps only if that ServiceAccount exists and automounting is enabled. Create the account, reference it by name, and bind least-privilege RBAC to it.

My token file exists but calls still fail. Why? A present token that returns Unauthorized usually means it is expired or the ServiceAccount lacks RBAC. Check the token’s audience and add a suitable RoleBinding. Prompt templates for RBAC and workload identity live in the DevOps AI prompt library.

How do bound tokens differ from legacy secret tokens? Bound tokens are short-lived, audience-scoped, and rotated in place by the kubelet, so clients must re-read the file rather than caching it once. Legacy non-expiring secret tokens are discouraged. For more, see the Kubernetes & Helm guides.