Devspace dev `Error executing command 'touch /.devspace/start': Permission denied`

[samdish7]

What happened?

Running devspace dev fails with the error in the title when syncing changes upstream. Seems unable to create the file that signals when the syncing is completed, therefore not allowing devspace dev to finish starting, given it doesn't have permissions to access the /.devspace directory.

We have tried mapping in the directory and changing the permissions via our charts, but it then throws a read-only filesystem error, given devspace creates that dir itself.

We've also tried modifying and creating our own startup script to subvert this, but it doesn't appear to be able to be subverted as according to upstream.go in the GH repo, this path to touch the file is hardcoded.

What did you expect to happen instead?

Expected the sync to finish and allow for the dev suite to start up after waiting for the sync to be done to start the container (we have start up files that aren't capable of being hot-reloaded on a change), therefore we eventually want to allow devspace to auto restart the container. We of course, haven't gotten that far yet

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

Use the below devspace.yaml on an already running kubernetes cluster, after replacing the generic paths that I filled in

My devspace.yaml: (spacing is

version: v2beta1
name: code

pipelines:
  dev:
    run:
      run_dependencies --all
      ensure_pull_secrets --all
      create_deployments --all
      start_dev api

  deploy:
    run: |-
      run_dependencies --all
      ensure_pull_secrets --all
      build_images --all -t $(git describe --always)
      create_deployments --all
      
deployments:
  api:
    helm:
      chart:
        name:  <path/to/chart>
      valuesFiles: ["<path/to/values>", "<path/to/values2>"]

dev:
  api:
    imageSelector: private.registry/my/repo
    devImage: private.registry/my/repo:my_tag
    logs:
      enabled: true

    proxyCommands:
      - gitCredentials: true

    terminal:
      command: ./devspace_start.sh

    command: ["node", "/opt/app/app.js"]
    sync:
       - path: /path/to/src:/opt/app
         disableDownload: true
         startContainer: true
         initialSync: preferLocal
         printLogs: true
       - path: /path/to/common:/opt/app/common
         disableDownload: true
         initialSync: preferLocal
         printLogs: true
       - path: ./devspace_start.sh
         file: true
         printLogs: true

commands:
  migrate-db:
    command: |-
      echo 'This is the default devspace placeholder stuff'

...

Local Environment:

• DevSpace Version: 6.3.17
• Operating System: RHEL 9
• ARCH of the OS: AMD64
  Kubernetes Cluster:
• Cloud Provider: aws
• Kubernetes Version: v1.33.0

Anything else we need to know?
Not sure if we are missing something or not, but we haven't been able to find anything related to this permission denied error that we are getting. We are also unable to run as root on our pods.

[dajrivera]

This is most likely due to running your deployment / dev containers as non-root. This particular issue can be worked around with something like the following:

deployments:
  my-app:
    namespace: my-namespace
    helm:
      chart:
        name: component-chart
        repo: https://charts.devspace.sh
      values:
        containers:
        - image: ${IMAGE}
          command: ['sleep', 'infinity']
          securityContext:
            # Expression is a workaround to output as int instead of string
            runAsUser: $(echo ${CONTAINER_UID})
            runAsGroup: $(echo ${CONTAINER_GID})
          volumeMounts:
          - containerPath: /.devspace
            volume:
              name: devspace-tmp
        securityContext:
          fsGroup: $(echo ${CONTAINER_GID})
          fsGroupChangePolicy: OnRootMismatch
        volumes:
        - name: devspace-tmp
          emptyDir:
            medium: Memory
            sizeLimit: 4Mi

The /.devspace/start file is used to pause execution of your container command until the initial sync is complete so I'm unsure if it would cause sync errors.