When migrating workloads to OpenShift, one of the most common hurdles is data sharing. You might have a legacy VM writing logs or processing files and a modern containerized app that needs to read them—or vice versa.
While OpenShift natively supports NFSv4, getting “identical visibility” across both environments requires a bit of finesse. Here is how to handle NFS mounting without compromising security or breaking the OpenShift security model.
The “Don’t Do This” List
Before we dive into the solution, it’s important to understand why the “obvious” paths often lead to trouble:
- Avoid Custom SCCs for Direct Container Mounts You could technically mount the NFS share directly inside the container. However, in OpenShift, Pods run under restricted Security Context Constraints (SCCs). Bypassing these with a custom SCC opens up attack vectors. It’s better to let the platform handle the mount.
- Don’t Hack the CSI Driver You might be tempted to force a dynamic provisioner to use a specific root path. This is a bad move. CSI drivers create unique subfolders for a reason: to prevent App A from accidentally (or maliciously) seeing App B’s data. Breaking this breaks your security isolation.
The Solution: Static PersistentVolumes
The most robust way to ensure a VM and a Pod see the exact same folder is by using a Static PersistentVolume (PV). This bypasses the dynamic provisioner’s tendency to create unique subfolders, allowing you to point OpenShift exactly where the VM is looking.
1. Define the Static PersistentVolume
You must manually define the PV. This allows you to hardcode the server and path to match the VM’s mount point.
apiVersion: v1
kind: PersistentVolume
metadata:
name: shared-pv
spec:
capacity:
storage: 100Gi # Required but not used with nfs
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain # Data survives PVC deletion
nfs:
path: /srv/nfs_dir # The identical path used by your VM
server: nfs-server.example.comImportant Server-Side Config To avoid “UID/GID havoc,” ensure your NFS server export is configured with: rw,sync,no_root_squash,no_all_squash. This prevents the server from rewriting IDs, which is vital when OpenShift’s secure containers use random UIDs. See the Cloud Pak for Data article for more details
2. Create the PersistentVolumeClaim (PVC)
Next, create a PVC that binds specifically to the static PV you just created. By setting the storageClassName to an empty string, you tell OpenShift not to look for a dynamic provisioner.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: shared-pvc
namespace: your-app-namespace
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 100Gi
volumeName: shared-pv # Direct binding to the static PV
storageClassName: "" # Keep this empty to avoid dynamic provisioning3. Mount the PVC in your Pod
Finally, reference the PVC in your Pod’s volume definition. This is where the magic happens: the container sees the filesystem exactly as the VM does.
apiVersion: v1
kind: Pod
metadata:
name: shared-data-app
spec:
containers:
- name: app-container
image: my-app-image
volumeMounts:
- name: nfs-storage
mountPath: /var/data/shared
volumes:
- name: nfs-storage
persistentVolumeClaim:
claimName: shared-pvcMount Options
NFS can be picky. If your server requires specific versions or security flavors, add a mountOptions section to your PV definition to match the VM’s parameters exactly (e.g., nfsvers=4.1 or sec=sys).
Summary
By using a Static PV, you treat the NFS share as a known, fixed resource rather than a disposable volume. This keeps your OpenShift environment secure, your SCCs restricted, and your data perfectly synced between your infrastructure layers.