+++ This bug was initially created as a clone of Bug #1643167 +++
Description of problem:
Using manila-provisioner in OpenShift creates a manila share on OpenStack. When is mounted on the POD:
172.20.2.21:/volumes/_nogroup/0840a9cc-8936-4b25-8a45-3ff92d7a5f55 2097152 0 2097152 0% /test-manila
The permissions are the following
sh-4.2$ ls -ld /test-manila/
drwxr-xr-x. 1 nobody nobody 0 Oct 25 15:34 /test-manila/
The user executing the pod is the following:
sh-4.2$ id
uid=1000180000 gid=0(root) groups=0(root),1000180000
Version-Release number of selected component (if applicable):
rhceph-3-rhel7:3-11
How reproducible:
Steps to Reproduce:
1. Create a PVC on Openshift
2. Wait till PV is created
3. Add volume for the pod in the deployment config
Actual results:
Pod is not able to write in the NFS share due to 755
Expected results:
Able to write in the share, a 775 or 2775
Additional info:
Another option it would be create the directory with nfsnobody and run the containers following OCP instructions for NFS:
https://docs.openshift.com/container-platform/3.11/install_config/persistent_storage/persistent_storage_nfs.html#nfs-user-ids
--- Additional comment from John Fulton on 2018-10-25 18:10:34 UTC ---
Tom, Do you think this falls under Manila or CephFS?
--- Additional comment from Tom Barron on 2018-10-26 02:40:11 UTC ---
(In reply to John Fulton from comment #1)
> Tom, Do you think this falls under Manila or CephFS?
John, I agree with the re-assignment. Probably we need (1) a configuration option in manila to choose the mode and (2) a new BZ (in which case I'll create it) on ceph-volume library itself to actually implement the mode setting. Currently the ceph-volume library hard-codes 0755 so we do need a change there too. I can see in an abstract sense why the bug reporter would think Ceph-DFG would own this one but from a practical standpoint we will drive this from Manila since Manila is the only current OpenStack user of the ceph-volume library.
--- Additional comment from PnT Account Manager on 2018-11-28 22:29:45 UTC ---
Employee 'dschoenb' has left the company.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2019:0591