[BUG] wrong owner in local-path-provisioner volumes

[irizzant]

What did you do

I created a cluster as reported, and deployed a Pod with a PersistentVolumeClaim, manifest below.

Pod

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  terminationGracePeriodSeconds: 1
  containers:
  - image: busybox
    command: ["sleep","50000"]
    name: test
    resources: {}
    volumeMounts:
      - name: testmount
        mountPath: /test/claim
      - name: testemptydir
        mountPath: /test/emptydir
  securityContext:
    fsGroup: 1001
    runAsUser: 1001
  volumes:
    - name: testmount
      persistentVolumeClaim:
        claimName: claim
    - name: testemptydir
      emptyDir: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 1Gi

• How was the cluster created?
  • k3d cluster create -c config.yaml

apiVersion: k3d.io/v1alpha2
name: test
kind: Simple
image: docker.io/rancher/k3s:v1.21.5-k3s1
servers: 1
volumes:
  - volume: /tmp/calico.yaml:/var/lib/rancher/k3s/server/manifests/calico.yaml
options:
  k3s:
    extraServerArgs:
      - --no-deploy=traefik

• What did you do afterwards?
  I exec into the test Pod and we have:

/test $ ls -al 
total 16
drwxr-xr-x    4 root     root          4096 Sep 27 20:20 .
drwxr-xr-x    1 root     root          4096 Sep 27 20:20 ..
drwxrwxrwx    2 root     root          4096 Sep 27 20:20 claim
drwxrwsrwx    2 root     1001          4096 Sep 27 20:20 emptydir

See above the emptyDir gets the correct group 1001 while "claim" directory has instead root group, which shouldn't.

I think this is due to the configuration of the local-volume-provisioner:

setup:
----
#!/bin/sh
while getopts "m:s:p:" opt
do
    case $opt in
        p)
        absolutePath=$OPTARG
        ;;
        s)
        sizeInBytes=$OPTARG
        ;;
        m)
        volMode=$OPTARG
        ;;
    esac
done
mkdir -m 0777 -p ${absolutePath}
chmod 701 ${absolutePath}/..
teardown:

See above that the volumes are created with 777 permissions but there is no setting for the group.

What did you expect to happen

The "claim" directory should have 1001 group.

Screenshots or terminal output

Which OS & Architecture

• Ubuntu 20.10

Which version of k3d

• output of k3d version

k3d version v4.4.8
k3s version v1.21.3-k3s1 (default)

Which version of docker

Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:54:09 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:52:16 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
 Containers: 14
  Running: 2
  Paused: 0
  Stopped: 12
 Images: 185
 Server Version: 20.10.8
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e25210fe30a0a703442421b0f60afac609f950a3
 runc version: v1.0.1-0-g4144b63
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.8.0-63-generic
 Operating System: Ubuntu 20.10
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.672GiB
 Name: NB-IRIZZANTE
 ID: LOBD:TQFE:V6ER:JP4C:3IIS:LWNA:KY2I:6EWW:O3FR:Q7TP:ZLRD:TDUG
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: irizzant
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[iwilltry42]

Hi @irizzant , thanks for opening this issue! However, k3d doesn't configure anything for the local-path-provisioner, as that's a service of K3s itself. See the following resources:

• https://github.com/rancher/local-path-provisioner
• https://github.com/k3s-io/k3s/blob/master/manifests/local-storage.yaml
  You can edit it e.g. as mentioned here: How to configure local-path provisioner? #787 (comment)

However, there were also some changes to the ownership which were shipped with a more recent version of K3s, see e.g. #743 (comment)

[irizzant]

Hi @iwilltry42
I see.
I also see there is a new k3d version with a new k3s version as reported here with a fix for the issue.

I'm going to close this.

Thanks