Introduction

Exit code 126 usually means a command was found but could not be executed. With kubectl cp, the most common cause is that the container image does not have a working tar binary, because kubectl cp relies on tar inside the container to package and unpack files.

Why kubectl cp Depends on tar

kubectl cp is not a low-level file-copy protocol. Under the hood, it streams a tar archive between your machine and the target container. That means both sides need the required tooling to create or extract the archive.

A typical copy command looks simple:

kubectl cp ./config.yaml my-pod:/tmp/config.yaml

But if the container does not have tar, or if tar exists without execute permission, the command can fail with exit code 126.

Verify the Container Environment

The first thing to check is whether tar is present and executable inside the target container:

kubectl exec my-pod -- tar --version

If that command fails, you have found the real problem. Many minimal images intentionally omit utilities such as tar to reduce image size.

You should also verify file-system permissions if you are copying into a protected directory:

kubectl exec my-pod -- sh -c "touch /tmp/test-file && rm /tmp/test-file"

If the directory is not writable, the copy can also fail even when tar itself exists.

Common Fixes

The cleanest fix is to use an image that includes tar or to install it in the image build if that matches your security and image-size policy.

For example, in a Debian-based image:

RUN apt-get update && apt-get install -y tar && rm -rf /var/lib/apt/lists/*

If you cannot change the image, use a different transfer approach. For a single small file, you can sometimes stream content through kubectl exec:

cat ./config.yaml | kubectl exec -i my-pod -- sh -c "cat > /tmp/config.yaml"

That is not as convenient as kubectl cp, but it avoids the container-side tar dependency.

Check the Exact Container and Path

In multi-container Pods, kubectl cp may target a different container than the one you expect. If only one container has the needed tools, specify it explicitly:

kubectl cp ./config.yaml my-pod:/tmp/config.yaml -c app

Also make sure the destination path exists and is appropriate for the user the container runs as. Copying into a root-owned location while the container runs as a non-root user is another easy way to hit execution or permission problems.

Common Pitfalls

The biggest mistake is diagnosing exit code 126 only at the kubectl level and not checking the container itself. In many cases, kubectl is fine and the container image is simply too minimal for kubectl cp to work as expected.

Another issue is assuming tar missing always produces only one exact message. Depending on the image and shell environment, you may see different stderr output even though the root cause is the same.

Developers also sometimes test the command against one Pod and then assume every Pod built from the same application has the same utilities. Sidecars, debug images, and init-container differences can make that assumption false.

Finally, do not ignore the destination directory permissions. A working tar binary is necessary, but it is not sufficient if the target path is not writable or the file system is read-only.

Summary

• Exit code 126 usually means a command was found but could not be executed.
• 'kubectl cp commonly fails this way when the target container lacks a usable tar binary.'
• Check tar --version inside the container before debugging anything more complicated.
• Verify the destination path, permissions, and selected container in multi-container Pods.
• If needed, use kubectl exec with streamed input as a fallback copy method.