Cloud Native 7 min read

Retrieving and Accessing Jenkins Job Workspace on Kubernetes Using NFS Mount

This article explains how to solve the problem of losing Jenkins job artifacts when using dynamic Kubernetes agents by mounting the slave workspace to the master via NFS, modifying pipeline code, and accessing the workspace through the Jenkins UI, complete with step‑by‑step instructions and troubleshooting tips.

JD Tech
JD Tech
JD Tech
Retrieving and Accessing Jenkins Job Workspace on Kubernetes Using NFS Mount

Jenkins is a core CI/CD tool in many DevOps pipelines, and when using dynamic agents on a Kubernetes cluster, the workspace of a job resides inside a temporary pod that is destroyed after the build finishes, causing the compiled artifacts to disappear.

The proposed solution is to synchronize the slave (agent) workspace with the master node by mounting the slave's workspace directory to a path under $JENKINS_HOME/workspace on the master using NFS. This ensures that files remain available after the pod is terminated.

Implementation steps include:

Install and start NFS services on the master node, configure access permissions.

Add an NFS volume definition to the Jenkins pipeline (Jenkinsfile) so that each pod mounts the shared directory.

Example pipeline snippet:

podTemplate(...) {
    volumes: [
        nfsVolume(mountPath: 'slave workspace',
                  serverAddress: 'master IP',
                  serverPath: 'master workspace',
                  readOnly: false)
    ]
    // other pipeline steps
}

After applying the changes, the workspace can be accessed from the Jenkins UI by navigating to a specific build, selecting Pipeline Steps , and clicking Allocate node: Start , which now points to the synchronized directory on the master.

If errors occur (e.g., file not found), the issue is typically that the UI still tries to locate the workspace on the now‑deleted slave node. By inspecting the plugin source code ( WorkspaceActionImpl.java and related classes), it is clear that the node name and path need to be overridden to reference the master node (empty string for the master node name).

After adjusting the plugin code to return the master node and correct path, the workspace becomes visible and downloadable directly from the Jenkins page, confirming that the NFS‑based synchronization works as intended.

The article concludes with a successful verification screenshot and a reminder that the entire process enables persistent access to build artifacts without relying on external storage services.

ci/cdkubernetesdevopsWorkspaceJenkinsNFS
JD Tech
Written by

JD Tech

Official JD technology sharing platform. All the cutting‑edge JD tech, innovative insights, and open‑source solutions you’re looking for, all in one place.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.