Description of problem: End user cannot write data to mounted dir with azure file Version-Release number of selected component (if applicable): openshift v3.9.0-0.36.0 kubernetes v1.9.1+a0ce1bc657 How reproducible: Awayls Steps to Reproduce: $ oc get project wehe -o yaml apiVersion: v1 kind: Project metadata: annotations: openshift.io/description: "" openshift.io/display-name: "" openshift.io/requester: wehe openshift.io/sa.scc.mcs: s0:c12,c4 openshift.io/sa.scc.supplemental-groups: 1000140000/10000 openshift.io/sa.scc.uid-range: 1000140000/10000 creationTimestamp: 2018-02-06T03:35:12Z name: wehe resourceVersion: "34160" selfLink: /oapi/v1/projects/wehe uid: bd07f3a8-0aee-11e8-831a-000d3a1923d0 spec: finalizers: - openshift.io/origin - kubernetes status: phase: Active And we can only create pod with the runAsUser as range 1000140000/10000, fsGroup of the range 1000140000/10000, but whatever I set, the mounted dir can not be writeable for the end user. $ cat azpvcpod.yaml apiVersion: v1 kind: Pod metadata: name: azfpo1 spec: containers: - image: jhou/hello-openshift name: azure volumeMounts: - name: azure mountPath: /mnt/azf securityContext: supplementalGroups: - 333 runAsUser: 1000140000 fsGroup: 1000140000 seLinuxOptions: level: "s0:c12,c4" volumes: - name: azure persistentVolumeClaim: claimName: pvc $ oc get pods azfpo1 1/1 Running 0 11m $ oc exec -it azfpo1 bash bash-4.2$ id uid=1000140000 gid=0(root) groups=0(root),333,1000140000 bash-4.2$ ls -lZd /mnt/azf/ drwxr-xr-x. root root system_u:object_r:cifs_t:s0 /mnt/azf/ bash-4.2$ touch /mnt/azf/wehe touch: cannot touch '/mnt/azf/wehe': Permission denied To deep investigate, I found the mount mode of the dir and file is 0755 by default, so I think it is the root cause of why admin can write data to the dir but end user cannot. Mounting arguments: --description=Kubernetes transient mount for /var/lib/origin/openshift.local.volumes/pods/pod_uid/volumes/kubernetes.io~azure-file/azpv --scope -- mount -t cifs -o username=xxxxxx ,file_mode=0755,dir_mode=0755,vers=3.0... Actual results: End user cannot write data to the mounted dir Expected results: We have options or we change the default mode so that end user can actually use the azure file storage Additional info:
origin PR https://github.com/openshift/origin/pull/18526
Tested on below version: openshift v3.9.0-0.47.0 kubernetes v1.9.1+a0ce1bc657 I found two ways that end user can write data to the mounted dir: 1. From the upstream issue: https://github.com/kubernetes/kubernetes/issues/54610#issuecomment-347092965, I created a pv with the uid set to be consist with the pod # cat azf-pv.yml apiVersion: "v1" kind: "PersistentVolume" metadata: name: "azpv" spec: capacity: storage: "1Gi" accessModes: - "ReadWriteMany" azureFile: secretName: azure-secret shareName: azftest readOnly: false mountOptions: - uid=1000140000 $ oc get pods NAME READY STATUS RESTARTS AGE azfpod1 1/1 Running 0 8m $ oc exec -it azfpod1 bash bash-4.2$ id uid=1000140000 gid=0(root) groups=0(root),1000140000 bash-4.2$ ls -lZd /mnt/azf/ drwxr-xr-x. 1000140000 1000140000 system_u:object_r:cifs_t:s0 /mnt/azf/ bash-4.2$ touch /mnt/azf/wehe 2. Set the dir_mode with 0775 so group user can write data # cat azf-pv.yml apiVersion: "v1" kind: "PersistentVolume" metadata: name: "azpv" spec: capacity: storage: "1Gi" accessModes: - "ReadWriteMany" azureFile: secretName: azure-secret shareName: azftest readOnly: false mountOptions: - dir_mode=0775 - file_mode=0775 $ oc get pods NAME READY STATUS RESTARTS AGE azfpod1 1/1 Running 0 2m $ oc exec -it azfpod1 bash bash-4.2$ id uid=1000140000 gid=0(root) groups=0(root),1000140000 bash-4.2$ ls -lZd /mnt/azf/ drwxrwxr-x. root 1000140000 system_u:object_r:cifs_t:s0 /mnt/azf/ bash-4.2$ touch /mnt/azf/test bash-4.2$ ls /mnt/azf/ test wehe
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-2018:0489