-2

Environment: external NFS share for persistent storage, accessible to all, R/W, Centos7 VMs (NFS share and K8s cluster), NFS utils installed on all workers.

Mount on a VM, e.g. a K8s worker node, works correctly, the share is R/W

Deployed in the K8s cluster: PV, PVC, Deployment (Volumes - referenced to PVC, VolumeMount) The structure of the YAML files corresponds to the various instructions and postings, including the postings here on the site.

The pod starts, the share is mounted. Unfortunately, it is read-only. All the suggestions from the postings I have found about this did not work so far.

Any idea what else I could look out for, what else I could try?

Thanks. Thomas

Thomas
  • 11
  • 3
  • Is it mounted RO by client, or is it exported with `ro` option? Or is it problem of mismatched UID? – rkosegi Feb 16 '21 at 09:40
  • `All the suggestions from the postings I have found about this did not work so far.` - what exactly did you tried and why it didn't help? – rkosegi Feb 16 '21 at 09:44
  • It is exorted with rw. One can mount the share in a system (outside K8s) and read and write w/o any problems. It seems, that the client (K8s / my Pod?) mount it ro. – Thomas Feb 16 '21 at 17:07
  • Check the ownership of the files at the nfs share point. It should be `nobody` or with the `UID` that matches your POD's user – FJunqueira Jun 03 '22 at 02:01

2 Answers2

1

After digging deep, I found the cause of the problem. Apparently, the syntax for the NFS export is very sensitive. One more space can be problematic. On the NFS server, two export entries were stored in the kernel tables. The first R/O and the second R/W. I don't know whether this is a Centos bug because of the syntax in /etc/exports.

On another Centos machine I was able to mount the share without any problems (r/w). In the container (Debian-based image), however, not (only r/o). I have not investigated whether this is due to Kubernetes or Debian behaves differently.

After correcting the /etc/exports file and restarting the NFS server, there was only one correct entry in the kernel table. After that, mounting R/W worked on a Centos machine as well as in the Debian-based container inside K8s.

Here are the files / table:

privious /etc/exports:

/nfsshare 172.16.6.* (rw,sync,no_root_squash,no_all_squash,no_acl)

==> kernel:

/nfsshare 172.16.6.*(ro, ...
/nfsshare *(rw, ...

corrected /etc/exports (w/o the blank):

/nfsshare *(rw,sync,no_root_squash,no_all_squash,no_acl)

Thomas
  • 11
  • 3
0

In principle, the idea of using an init container is a good one. Thank you for reminding me of this.

I have tried it.

Unfortunately, it doesn't change the basic problem. The file system is mounted "read-only" by Kubernetes. The init container returns the following error message (from the log):

chmod: /var/opt/dilax/enumeris: Read-only file system

Thomas
  • 11
  • 3