+++ 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