Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker for Windows does not respect permissions for host volume provisioner #2048

Closed
2 tasks done
wojciechka opened this issue May 18, 2018 · 2 comments
Closed
2 tasks done

Comments

@wojciechka
Copy link

  • I have tried with the latest version of my channel (Stable or Edge)
  • I have uploaded Diagnostics
  • Diagnostics ID: CE998CAF-6215-4506-91E2-F043DC291CE8/2018-05-18_11-43-14

Expected behavior

Using helm chart stable/wordpress (version 1.0.6) works properly on Docker for Mac, Minikube, GKE and a custom K8s cluster that I have tested it on.

Actual behavior

Using Docker for Windows (VM based, not LCOW based) with Kubernetes enabled, installing tiller and deploying helm chart stable/wordpress results in permission denied error for mariadb pod that tries to change files in a volume.

Information

  • Windows Version: 18.03
  • Docker for Windows Version: 18.05 Edge

The mariadb container is running as non-root and the helm chart includes appropriate information to set the permissions. I am not sure this is the exact same version of helm chart for MariaDB, but it does set securityContext

https://github.com/kubernetes/charts/blob/6c661613cbe111c8a1ffa830e65f2304d079549d/stable/mariadb/templates/deployment.yaml#L24

So the host volume provisioner should be setting the right permissions for the volume to work.

Diagnostics upload id: CE998CAF-6215-4506-91E2-F043DC291CE8/2018-05-18_11-43-14

Here is a log of deploying the helm chart:

wojciech@surfacebook:~$ helm install stable/wordpress --version 1.0.6
NAME:   ideal-shark
LAST DEPLOYED: Fri May 18 11:39:07 2018
NAMESPACE: default
STATUS: DEPLOYED
(...)

wojciech@surfacebook:~$ helm list
NAME            REVISION        UPDATED                         STATUS          CHART           NAMESPACE
ideal-shark     1               Fri May 18 11:39:07 2018        DEPLOYED        wordpress-1.0.6 default

wojciech@surfacebook:~$ kubectl get pods
NAME                                     READY     STATUS                       RESTARTS   AGE
ideal-shark-mariadb-6c4f5bdcb6-rq4vh     0/1       Init:CrashLoopBackOff        1          10s
ideal-shark-wordpress-6649dc8f57-ddpgl   0/1       CreateContainerConfigError   0          10s

wojciech@surfacebook:~$ kubectl logs -c copy-custom-config ideal-shark-mariadb-6c4f5bdcb6-rq4vh
mkdir: can't create directory '/bitnami/mariadb/conf': Permission denied

wojciech@surfacebook:~$ kubectl describe pod ideal-shark-mariadb-6c4f5bdcb6-rq4vh
Name:           ideal-shark-mariadb-6c4f5bdcb6-rq4vh
Namespace:      default
Node:           docker-for-desktop/192.168.65.3
Start Time:     Fri, 18 May 2018 11:39:07 +0200
Labels:         app=ideal-shark-mariadb
                pod-template-hash=2709168762
Annotations:    <none>
Status:         Pending
IP:             10.1.0.24
Controlled By:  ReplicaSet/ideal-shark-mariadb-6c4f5bdcb6
Init Containers:
  copy-custom-config:
    Container ID:  docker://01c431570fbb6b97479be58878e03342339fae56838ad4ccfe80f6580403e1b0
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:58ac43b2cc92c687a32c8be6278e50a063579655fe3090125dcb2af0ff9e1a64
    Port:          <none>
    Command:
      sh
      -c
      mkdir -p /bitnami/mariadb/conf && cp /bitnami/mariadb_config/my.cnf /bitnami/mariadb/conf/my_custom.cnf
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Fri, 18 May 2018 11:40:36 +0200
      Finished:     Fri, 18 May 2018 11:40:36 +0200
    Ready:          False
    Restart Count:  4
    Environment:    <none>
    Mounts:
      /bitnami/mariadb from data (rw)
      /bitnami/mariadb_config from config (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-lbrqb (ro)
Containers:
  mariadb:
    Container ID:
    Image:          bitnami/mariadb:10.1.29-r1
    Image ID:
    Port:           3306/TCP
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:      250m
      memory:   256Mi
    Liveness:   exec [mysqladmin ping] delay=30s timeout=5s period=10s #success=1 #failure=3
    Readiness:  exec [mysqladmin ping] delay=5s timeout=1s period=10s #success=1 #failure=3
    Environment:
      MARIADB_ROOT_PASSWORD:  <set to the key 'mariadb-root-password' in secret 'ideal-shark-mariadb'>  Optional: false
      MARIADB_PASSWORD:       <set to the key 'mariadb-password' in secret 'ideal-shark-mariadb'>       Optional: false
      MARIADB_USER:           bn_wordpress
      MARIADB_DATABASE:       bitnami_wordpress
    Mounts:
      /bitnami/mariadb from data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-lbrqb (ro)
(...)

Version information:

wojciech@surfacebook:~$ docker version
Client:
 Version:      17.06.2-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   cec0b72
 Built:        Tue Sep  5 20:00:17 2017
 OS/Arch:      linux/amd64

Server:
 Version:      18.05.0-ce
 API version:  1.37 (minimum version 1.12)
 Go version:   go1.10.1
 Git commit:   f150324
 Built:        Wed May  9 22:20:16 2018
 OS/Arch:      linux/amd64
 Experimental: true

wojciech@surfacebook:~$ docker info
Containers: 53
 Running: 37
 Paused: 0
 Stopped: 16
Images: 28
Server Version: 18.05.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.87-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.837GiB
Name: linuxkit-00155d199a29
ID: OPI3:GBFV:TUKO:XZCY:MXYM:2GGC:LYHT:QUTO:ABG6:Y2QG:WZ63:K46A
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 221
 Goroutines: 188
 System Time: 2018-05-18T09:42:11.438764Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

wojciech@surfacebook:~$ kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:13:31Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

wojciech@surfacebook:~$ helm version
Client: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.0", GitCommit:"14af25f1de6832228539259b821949d20069a222", GitTreeState:"clean"}

Steps to reproduce the behavior

  1. Install helm in the K8s inside Docker for Windows (see https://docs.helm.sh/using_helm/#quickstart-guide and https://github.com/kubernetes/helm) and client locally
  2. Run helm update repo (to ensure version 1.0.6 is available as a helm chart - it may not be needed)
  3. Run helm install stable/wordpress --version 1.0.6
  4. The mariadb pod for the deployment is now failing
@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Jun 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants