permission denied during file sync

[frank-bee]

What happened?
I get permission denied error during file sync
e.g.

dev:app sync  Waiting for initial sync to complete
dev:app sync  Initial sync completed
start_dev: initial sync: upstream: apply changes: apply creates: upload archive: after upload: rpc error: code = Unknown desc = untar all: decompress: create /app/.eslintrc.js: open /app/.eslintrc.js: permission denied

What did you expect to happen instead?
devspace dev should not hang in filesync but sync the files and open a shell in the dev pod

How can we reproduce the bug? (as minimally and precisely as possible)
run devspace dev

My devspace.yaml:

version: v2beta1
name: mtracegit

# This is a list of `pipelines` that DevSpace can execute (you can define your own)
pipelines:
  # You can run this pipeline via `devspace deploy` (or `devspace run-pipeline deploy`)
  deploy:
    run: |-
      run_dependencies --all                            # 1. Deploy any projects this project needs (see "dependencies")
      ensure_pull_secrets --all                         # 2. Ensure pull secrets
      build_images --all -t $(git describe --always)    # 3. Build, tag (git commit hash) and push all images (see "images")
      create_deployments --all                          # 4. Deploy Helm charts and manifests specfied as "deployments"
  # This is the pipeline for the main command: `devspace dev` (or `devspace run-pipeline dev`)
  dev:
    run: |-
      run_dependencies --all       # 1. Deploy any projects this project needs (see "dependencies")
      ensure_pull_secrets --all    # 2. Ensure pull secrets
      create_deployments --all     # 3. Deploy Helm charts and manifests specfied as "deployments"
      start_dev app                # 4. Start dev mode "app" (see "dev" section)

# This is a list of `images` that DevSpace can build for this project
# We recommend to skip image building during development (devspace dev) as much as possible
images:
  app:
    image: myorgcrdev.azurecr.io/mtrace
    dockerfile: ./api/Dockerfile

# This is a list of `deployments` that DevSpace can create for this project
deployments:
  app:
    # This deployment uses `helm` but you can also define `kubectl` deployments or kustomizations
    helm:
      # We are deploying this project with the Helm chart you provided
      chart:
        name: .devspace/chart-repo
      # Under `values` we can define the values for this Helm chart used during `helm install/upgrade`
      # You may also use `valuesFiles` to load values from files, e.g. valuesFiles: ["values.yaml"]
      values:
        image:
          repository: myorgcrdev.azurecr.io/mtrace
          tag: latest
        connectorDng:
          image:
            repository: myorgcrdev.azurecr.io/mtrace-connector-dng
            tag: latest
        global:
          postgresql:
            auth:
              createExistingSecret: true

# This is a list of `dev` containers that are based on the containers created by your deployments
dev:
  app:
    arch: amd64
    # Search for the container that runs this image
    imageSelector: myorgcrdev.azurecr.io/mtrace
    # Replace the container image with this dev-optimized image (allows to skip image building during development)
    #devImage: ghcr.io/loft-sh/devspace-containers/javascript:18-alpine
    devImage: ghcr.io/loft-sh/devspace-containers/typescript:18-alpine
    # Sync files between the local filesystem and the development container
    sync:
      - path: ./api/:./
        disableDownload: true
        excludePaths:
          - integration-tests/
          - src/

    # Open a terminal and use the following command to start it
    terminal:
      command: ./devspace_start.sh
    # Inject a lightweight SSH server into the container (so your IDE can connect to the remote dev env)
    #ssh:
    #  enabled: true
    # Make the following commands from my local machine available inside the dev container
    proxyCommands:
      - command: devspace
      - command: kubectl
      - command: helm
      - gitCredentials: true
    # Forward the following ports to be able access your application via localhost
    ports:
      - port: "9229"
      - port: "8080"
    # Open the following URLs once they return an HTTP status code other than 502 or 503
    open:
      - url: http://localhost:8080

# Use the `commands` section to define repeatable dev workflows for this project 
commands:
  migrate-db:
    command: |-
      echo 'This is a cross-platform, shared command that can be used to codify any kind of dev task.'
      echo 'Anyone using this project can invoke it via "devspace run migrate-db"'
hooks:
  - events:
      - before:deploy
    command: if [ -d '.devspace/chart-repo/.git' ]; then cd ".devspace/chart-repo" && git pull origin main; else mkdir -p .devspace/chart-repo; git clone --single-branch --branch main [email protected]:myorg/mtrace-chart.git .devspace/chart-repo; fi

Local Environment:

• DevSpace Version: 6.3.13
• Operating System: mac
• ARCH of the OS: ARM64
  Kubernetes Cluster:
• Cloud Provider: local kind cluster using podman
• Kubernetes Version:
• (☸|kind-mtrace:mtrace)➜ ~ kubectl version
  Client Version: v1.31.1
  Kustomize Version: v5.4.2
  Server Version: v1.31.0

Anything else we need to know?
If I enter the dev pod and type whoami , I see user 1001 instead of root

[frank-bee]

I fixed it with this config

# This is a list of `deployments` that DevSpace can create for this project
deployments:
  app:
    # This deployment uses `helm` but you can also define `kubectl` deployments or kustomizations
    helm:
      # We are deploying this project with the Helm chart you provided
      chart:
        name: .devspace/chart-repo
      # Under `values` we can define the values for this Helm chart used during `helm install/upgrade`
      # You may also use `valuesFiles` to load values from files, e.g. valuesFiles: ["values.yaml"]
      values:
        securityContext:
          runAsUser: 0

but is it required to run the devcontainer as root?

[lizardruss]

@frank-bee

Currently, yes it's required to run the ghcr.io/loft-sh/devspace-containers/typescript:18-alpine image as root to avoid this issue. This image is provided for convenience, but if you have restrictions that prevent you from running it as root, then it should be straightforward to use the Dockerfile here as a starting point to customize it for your needs.

A common pattern we use is just define a "dev image" build in the devspace.yaml, since our development image needs quickly expanded outside the common use case.

Another solution might be to use pod patches to set runAsUser: 0. This should work with any deployment method / helm chart.