<p>Setup:
Linux VM where Pod (containing 3 containers) is started.
Only 1 of the containers needs the NFS mount to the remote NFS server.
This &quot;app&quot; container is based Alpine linux.</p>
<p>Remote NFS server is up &amp; running. If I create a separate yaml file for persistent volume with that server info - it's up &amp; available.</p>
<p>In my pod yaml file I define Persistent Volume (with that remote NFS server info), Persistent Volume Claim and associate my &quot;app&quot; container's volume with that claim.
Everything works as a charm if on the hosting linux VM I install the NFS library, like:
<code>sudo apt install nfs-common</code>.
(That's why I don't share my kubernetes yaml file. Looks like problem is not there.)</p>
<p>But that's a development environment. I'm not sure how/where those containers would be used in production. For example they would be used in AWS EKS.
I hoped to install something like
<code>apk add --no-cache nfs-utils</code> in the &quot;app&quot; container's Dockerfile.
I.e. on container level, not on a pod level - could it work?</p>
<p>So far getting the pod initialization error:</p>
<pre><code>Events:
  Type     Reason            Age               From               Message
  ----     ------            ----              ----               -------
  Warning  FailedScheduling  35s               default-scheduler  0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
  Warning  FailedScheduling  22s               default-scheduler  0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.
  Normal   Scheduled         20s               default-scheduler  Successfully assigned default/delphix-masking-0 to masking-kubernetes
  Warning  FailedMount       4s (x6 over 20s)  kubelet            MountVolume.SetUp failed for volume &quot;nfs-pv&quot; : mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs -o hard,nfsvers=4.1 maxTestNfs1.dlpxdc.co:/var/tmp/masking-mount /var/snap/microk8s/common/var/lib/kubelet/pods/2e6b7aeb-5d0d-4002-abba-88de032c12dc/volumes/kubernetes.io~nfs/nfs-pv
Output: mount: /var/snap/microk8s/common/var/lib/kubelet/pods/2e6b7aeb-5d0d-4002-abba-88de032c12dc/volumes/kubernetes.io~nfs/nfs-pv: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.&lt;type&gt; helper program.
</code></pre>
<p>And the process is stuck in that step forever.
Looks like it happens before even trying to initialize containers.
So I wonder if approach of enabling NFS-client on the container's level is valid.
Thanks in ahead for any insights!</p>

Max
<p><code>I hoped to install something like apk add --no-cache nfs-utils in the &quot;app&quot; container's Dockerfile. I.e. on container level, not on a pod level - could it work?</code></p>
<p>Yes, this could work. This is normally what you would do if you have no control to the node (eg. you can't be sure if the host is ready for NFS calls). You need to ensure your pod can reach out to the NFS server and in between all required ports are opened. You also needs to ensure required NFS program (eg. rpcbind) is <a href="https://github.com/walkerk1980/docker-nfs-client/blob/master/entry.sh" rel="nofollow noreferrer">started</a> before your own program in the container.</p>
<p><code>...For example they would be used in AWS EKS.</code></p>
<p>EKS optimized AMI come with NFS supports, you can leverage K8S PV/PVC support using this image for your worker node, there's no need to initialize NFS client support in your container.</p>
