Build fail on Kubernetes agent after upgrading the kubernetes plugin to 1.18.0 or later

After upgrading to CloudBees Core version 2.176.4.3 or newer, or Kubernetes plugin version 1.18.0 or later, your builds which use their own Docker containers start to fail with "permission denied" or similar errors accessing files within /home/jenkins.

Kubernetes plugin version 1.18.0 changed the default Working Directory for agents from /home/jenkins to /home/jenkins/agent. This change was made because the Kubernetes plugin uses an emptyDir volume to mount the agent remote directory. Users who built their own containers and put data in the /home/jenkins directory couldn’t access that data because it was masked when the working directory was mounted on top of it. See [JENKINS-58705] for more on this issue.

In some specific cases - where the working directory was specifically set for containers - this may be a breaking change. As this could result in containers having the working directory mounted in different location. A general rule is that all containers in the pod should have their workingDir pointing to the same location. And if the workingDir is not explicitly set, it will be set to the same value as the jnlp container.

Make sure that all containers have their working directory (i.e. workingDir) pointing to the same location.

Revert back to using /home/jenkins as the working directory

A workaround is to change the working directory of pod containers back to /home/jenkins. This workaround is only possible when using YAML to define agent pod templates (see JENKINS-60977).