<p>My remotely working setup is as follows:</p>
<p><code>PersistentVolume</code> is mounted to a <code>gcePersistentDisk</code>. Pod &quot;Lagg&quot; makes a claim on the entirety of the persistent disk. &quot;Lagg&quot; is a google containers <a href="http://gcr.io/google-containers/volume-nfs" rel="nofollow noreferrer">volume-nfs</a> image, which acts as the middleman between the <code>ReadWriteOnce</code> volume and a NFS <code>ReadWriteMany</code> that all of my other pods can access. Below is the Lagg NFS persistent volume YAML:</p>
<pre><code>apiVersion: v1
kind: PersistentVolume
metadata:
  name: lagg-volume
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  nfs:
    # kustomize does not add prefixes here, so they're placed ahead of time
    server: test-lagg.test-project.svc.cluster.local
    path: &quot;/&quot;

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lagg-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: &quot;&quot;
  resources:
    requests:
      storage: 5Gi
</code></pre>
<p>There is a second <code>PersistentVolume</code> that mounts to the pod via NFS, that other pods can claim. One of those pods is &quot;Digit&quot; which you can see the volume defining part below:</p>
<pre><code>spec:
  template:
    spec:
      containers:
      - name: digit
        volumeMounts:
          - name: lagg-connection
            mountPath: &quot;/cache&quot;
      volumes:
      - name: lagg-connection
        persistentVolumeClaim:
          claimName: lagg-claim
</code></pre>
<p>Because I don't have a <code>gcePersistentDisk</code> for local testing, my local version of this cluster instead uses another persistent volume called &quot;Lagg-local&quot; which simply takes the place of the <code>gcePersistentDisk</code>, and looks like this:</p>
<pre><code>apiVersion: v1
kind: PersistentVolume
metadata:
  name: lagg-local-volume
  labels:
    type: local
spec:
  storageClassName: manual
  persistentVolumeReclaimPolicy: Delete
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  local:
    path: /run/desktop/mnt/host/c/project/cache
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - docker-desktop
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lagg-local-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
</code></pre>
<p>When I try to run this locally, I only get one error, and it's in the Digit pod, using describe, it says:</p>
<pre><code>Events:
  Type     Reason       Age                From               Message
  ----     ------       ----               ----               -------
  Normal   Scheduled    47s                default-scheduler  Successfully assigned test-project/test-digit-cff6bd9c6-gz2sn to docker-desktop
  Warning  FailedMount  11s (x7 over 43s)  kubelet            MountVolume.SetUp failed for volume &quot;test-lagg-volume&quot; : mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs test-lagg.test-project.svc.cluster.local:/ /var/lib/kubelet/pods/80f686cf-47bb-478b-a581-c179794e2182/volumes/kubernetes.io~nfs/test-lagg-volume
Output: mount.nfs: Failed to resolve server test-lagg.test-project.svc.cluster.local: Name or service not known
</code></pre>
<p>From what I can see, the pods simply can't contact the NFS server or possibly can't resolve the DNS.
test-lagg exists and is running, and test-project is the namespace that both test-lagg (the service which points to the lagg NFS pods) and test-digit reside in. So I'm not entirely sure what is happening here.</p>
<p>I do believe the NFS server is working correctly, as a file &quot;index.html&quot; is created in the root of the volume that simply contains &quot;Hello from NFS!&quot;</p>
<p>The same error also happens if I use <code>cpuguy83/nfs-server</code> image instead of <code>google_containers/volume-nfs</code></p>
<p>A different error happens if I define the <code>clusterIP</code> rather than the DNS name, stating it doesn't have permissions.</p>
<p>I also don't think there's an issue with the connection to the service because running nslookup on the digit pod returns this:</p>
<pre><code>root@test-digit-7c6dc66659-q4trw:/var/www/static# nslookup test-lagg.test-project.svc.cluster.local
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   test-lagg.test-project.svc.cluster.local
Address: 10.105.85.125
</code></pre>
<p>The NFS pod itself also has the volume mounted correctly:</p>
<pre><code>On GKE:
PS C:\Users\ral\Documents\Projects\Project\Kubernetes&gt; kubectl exec next-lagg-69884bf49b-fn544 -- bash -c &quot;findmnt /exports -o TARGET,SOURCE,FSTYPE&quot;
TARGET   SOURCE   FSTYPE
/exports /dev/sdb ext4

On local:
PS C:\Users\ral\Documents\Projects\Project\Kubernetes&gt; kubectl exec test-lagg-547cbb779-4qgbl -- bash -c &quot;findmnt /exports -o TARGET,SOURCE,FSTYPE&quot;
TARGET   SOURCE             FSTYPE
/exports C:\[/Project/cache] 9p
</code></pre>

<p>DNS resolution problems with <code>google_containers/volume-nfs</code>, on non-GKE clusters, is a known issue:</p>
<ul>
<li><a href="https://github.com/kubernetes/examples/issues/390" rel="nofollow noreferrer">NFS example with a cluster local service name only works on GKE but not for minikube/kubeadm #390</a></li>
<li><a href="https://github.com/kubernetes/examples/issues/418" rel="nofollow noreferrer">Failed to resolve server nfs-server.default.svc.cluster.local: Name or service not known #418</a></li>
</ul>
<p>Basically, NFS server does not support hostnames, only IPs.</p>
<p>Alternatively you could use <a href="https://github.com/kubernetes-csi/csi-driver-nfs/blob/master/deploy/example/nfs-provisioner/README.md" rel="nofollow noreferrer">csi-driver-nfs</a></p>
