when create PVC, some of the pv are 755 permission

[zhangj1236]

In most cases, we can see the /opt/local-path-provisioner/xxx will have 777 permission, but some of them are 755, when this case happens, it will be no permission to write.
I used the following yaml file to create local-path.
My question are:
1)777 is expected, while 755 is not expected, right?
2)why in some cases, it will have 755 permission?

======================yaml file:
cat deploy-readWriteMany.yaml
apiVersion: v1
kind: Namespace
metadata:
name: local-path-storage

---

apiVersion: v1
kind: ServiceAccount
metadata:
name: local-path-provisioner-service-account
namespace: local-path-storage

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: local-path-provisioner-role
rules:

• apiGroups: [ "" ]
  resources: [ "nodes", "persistentvolumeclaims", "configmaps" ]
  verbs: [ "get", "list", "watch" ]
• apiGroups: [ "" ]
  resources: [ "endpoints", "persistentvolumes", "pods" ]
  verbs: [ "*" ]
• apiGroups: [ "" ]
  resources: [ "events" ]
  verbs: [ "create", "patch" ]
• apiGroups: [ "storage.k8s.io" ]
  resources: [ "storageclasses" ]
  verbs: [ "get", "list", "watch" ]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: local-path-provisioner-bind
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: local-path-provisioner-role
subjects:

• kind: ServiceAccount
  name: local-path-provisioner-service-account
  namespace: local-path-storage

---

apiVersion: apps/v1
kind: Deployment
metadata:
name: local-path-provisioner
namespace: local-path-storage
spec:
replicas: 1
selector:
matchLabels:
app: local-path-provisioner
template:
metadata:
labels:
app: local-path-provisioner
spec:
serviceAccountName: local-path-provisioner-service-account
containers:
- name: local-path-provisioner
image: a.b.c.d:5000/rancher/local-path-provisioner:v0.0.23
imagePullPolicy: IfNotPresent
command:
- local-path-provisioner
- --debug
- start
- --config
- /etc/config/config.json
volumeMounts:
- name: config-volume
mountPath: /etc/config/
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
volumes:
- name: config-volume
configMap:
name: local-path-config

---

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-path
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

---

kind: ConfigMap
apiVersion: v1
metadata:
name: local-path-config
namespace: local-path-storage
data:
config.json: |-
{
"sharedFileSystemPath": "/opt/local-path-provisioner"
}
setup: |-
#!/bin/sh
set -eu
mkdir -m 0777 -p "$VOL_DIR"
teardown: |-
#!/bin/sh
set -eu
rm -rf "$VOL_DIR"
helperPod.yaml: |-
apiVersion: v1
kind: Pod
metadata:
name: helper-pod
spec:
containers:
- name: helper-pod
image: a.b.c.d:5000/busybox:latest
imagePullPolicy: IfNotPresent

[Feyico]

I met the same problem，I have 3 Redis HA Pod，but only 1 Pod have the problem like you。In my opinion，if you have the dir in /opt/local-path-provisioner/xxx as 0755 mode，you could not change the mode to 0777 by command mkdir -m 0777 -p xxx. So I fix this problem this way:

1. run kubectl edit cm -n local-path-storage local-path-config
2. change the script setup like this

mkdir -m 0777 -p "$VOL_DIR"
chmod 0777 -R "$VOL_DIR"

If you don't want to recreate the PVC，you also can change the Pod's securityContext in spec.securityContext

securityContext:
  fsGroup: 0 #field specifies that for any Containers in the Pod, all processes run with user ID 0
  runAsUser: 0 #run with user ID 0, root
  runAsNonRoot: false

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.