Let's say you've a deployment that is mounting a Persistent Volume Claim.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: /var/data
          name: my-volume
      volumes:
      - name: my-volume
        persistentVolumeClaim:
          claimName: my-persistent-volume-claim

And when you try to create a file in the mounted Persistent Volume Claim, Permission Denied is being returned.

~]# oc exec pod/helloworld-0.0.6-snapshot-master-5-3-856cdf877d-pl5wt -- echo "Hello World" > /var/data/hello.txt
cannot create /var/data/hello.txt: Permission denied

It might be the case that the directory is owned by root (user 0) and only root has write permission to the directory, and if you are not root, you would lack write permission.

~]$ ls -ld /var/data
drwxr-xr-x.  2 root root   19 Jun  6  2018 /var/data

~]$ whoami
1000

Security Context fsGroup

In this scenario, you can try to setting Security Context fsGroup (file system group) to the user ID that need write access to the file system.

kind: Deployment
apiVersion: apps/v1
spec:
  template:
    spec:
      securityContext:
        runAsUser: 1000
        fsGroup: 1000

And then check to see if your user ID now has write permission to the directory.

~]$ ls -ld /var/data
drwxr-xr-x.  2 1000 root   19 Jun  6  2018 /var/data

runAsUser 0 (root)

Or you can allow the pod to be run as root. Often, if you try to run a pod as root, unable to validate against any security context constraint will be returned. 

Error creating: pods "my-deployment-" is forbidden: 
unable to validate against any security context constraint: [
 Forbidden: not usable by user or serviceaccount, provider "anyuid"
 Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid"
 Forbidden: not usable by user or serviceaccount, provider "hostnetwork"
 Forbidden: not usable by user or serviceaccount, provider "hostaccess"
 Forbidden: not usable by user or serviceaccount, provider "nonroot"
 Forbidden: not usable by user or serviceaccount, provider "privileged"
 Forbidden: not usable by user or serviceaccount, provider "restricted"
]

This occurs because the Security Context Contraint does not allow the pod to be run as root.

~]# oc get deployment my-app --output yaml --namespace my-project | oc adm policy scc-subject-review --filename -
RESOURCE            ALLOWED BY         
Deployment/my-app   hostmount-anyuid

You can create a Service Account.

~]$ oc create serviceaccount my-service-account
serviceaccount/my-service-account created

And then associate the Service Account with the privileged Security Context Constraint.

~]$ oc adm policy add-scc-to-user privileged -z my-service-account --namespace my-project
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:privileged added: "my-service-account"

And then edit the deployment with serviceAccountName and serviceAccount and runAsUser (and optionally runAsGroup and fsGroup).

spec:
  template:
    spec:
      serviceAccountName: my-service-account
      securityContext:
        runAsUser: 0
        runAsGroup: 0
        fsGroup: 0
      containers:
      - name: myapp
        image: api.openshift.example.com/myapp
        volumeMounts:
        - mountPath: /var/data
          name: my-volume
      serviceAccount: my-service-account
      volumes:
      - name: my-volume
        persistentVolumeClaim:
          claimName: my-persistent-volume-claim

Now the deployment should have the privileged Security Context Constraint.

~]# oc get deployment my-app --output yaml --namespace my-project | oc adm policy scc-subject-review --filename -
RESOURCE            ALLOWED BY         
Deployment/my-app   privileged

And the whoami command in the container should show that the pod is being run as root.

~]# oc exec pod/my-pod-7stht -- whoami
root