Kaniko "could not create /kaniko ... permission denied" in CI

By Daniel Zoghalchali·Latchkey

Kaniko writes its cache, layers, and the extracted rootfs under /kaniko and /. When the job runs as a user that cannot write there (a restrictive securityContext or a mismatched runAsUser), file creation fails with permission denied.

What this error means

Kaniko fails early with "could not create directory /kaniko/...: permission denied" or a similar EACCES on a path it needs to write during setup or unpacking.

error building image: could not create directory /kaniko/0: mkdir /kaniko/0:
permission denied

Common causes

A securityContext that blocks writes to /kaniko

A pod securityContext with a non-matching runAsUser or a read-only root filesystem prevents Kaniko from creating the directories it needs.

A volume mount owned by a different user

Mounting a cache or workspace volume owned by root while the container runs as another UID makes those paths unwritable.

How to fix it

Let Kaniko run as the user its image expects

1. Remove an overly strict runAsUser that conflicts with the Kaniko image.
2. Do not set readOnlyRootFilesystem for the Kaniko container.
3. If you mount a cache volume, set fsGroup or ownership so the container UID can write.

securityContext:
  runAsUser: 0
  # do not set readOnlyRootFilesystem: true for kaniko

Fix cache volume ownership

Ensure any mounted cache directory is writable by the container UID via fsGroup.

securityContext:
  fsGroup: 1000

How to prevent it

• Do not impose a read-only root filesystem on the Kaniko container.
• Match volume ownership (fsGroup) to the container UID for cache mounts.
• Avoid a runAsUser that conflicts with what the Kaniko image needs.

Frequently asked questions

Related guides

References

• Docker documentation
• Docker build cache
• GitHub Actions documentation