Answers: <p>If your ENTRYPOINT is <code>/home/django/start.sh</code> and you are mounting a volume on <code>home/django</code>, that's going to mask the contents of the <code>/home/django</code> directory. That means anything included in that directory (and its children) will be inaccessible in the running container.  This isn't Kubernetes-specific; this is exactly how the <code>mount</code> operation behaves in general.</p>
  <p>In general, the solution is to redesign your application to separate the static code from runtime resources, and have the application initialize the runtime directories when it starts up.</p>
  <p>If you're not able to modify the application, you may be able to accomplish your goal by using an <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" rel="nofollow noreferrer">init container</a> to copy the contents of <code>/home/django</code> into your volume. That process works by (a) first spawning an init container with the volume mounted at a different location (e.g., <code>/target</code>), (b) having the init container run a script that copies the contents of <code>/home/django</code> to <code>/target</code>, then (c) spawn your regular pod normally.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-04-10T15:44:45.093Z
Answers: 2023-04-10T15:44:45.093Z
Answers: larsks
Body: <p>There is an application in DockerHub and the working directory is <code>ENTRYPOINT /home/django/start.sh</code></p>
  <p>I want to add a persistent volume for /home/django foler but when I add it, it can't find start.sh in the logs of the pod. How should I integrate this. I am adding the lines I added to the following kubernetes deployment file.</p>
  <pre><code>        volumeMounts:
          - name: django-persistent-storage
            mountPath: /home/django/
        volumes:
        - name: django-persistent-storage
          persistentVolumeClaim:
            claimName: django-pv-claim
  </code></pre>
  <p>Logs:</p>
  <pre><code>Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: &quot;/home/django/start.sh&quot;: stat /home/django/start.sh: no such file or directory: unknown
  </code></pre>
  <p>This side is not very clear to me. I would like to know exactly what I'm missing. And how can I move the app to persistent volume?</p>
  
Tags: <kubernetes>
Title: Kubernetes Persistent volume not found start.sh issue
UserDisplayName: MrTux01
ThreadText: # Kubernetes Persistent volume not found start.sh issue
  
  (Asked by: username_0 on 2023-04-04)
  
  There is an application in DockerHub and the working directory is `ENTRYPOINT /home/django/start.sh`
  
  I want to add a persistent volume for /home/django foler but when I add it, it can't find start.sh in the logs of the pod. How should I integrate this. I am adding the lines I added to the following kubernetes deployment file.
  
  ```
          volumeMounts:
          - name: django-persistent-storage
            mountPath: /home/django/
        volumes:
        - name: django-persistent-storage
          persistentVolumeClaim:
            claimName: django-pv-claim
  
  ```
  
  Logs:
  
  ```
  Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/home/django/start.sh": stat /home/django/start.sh: no such file or directory: unknown
  
  ```
  
  This side is not very clear to me. I would like to know exactly what I'm missing. And how can I move the app to persistent volume?
  
  **Tags:** kubernetes
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-04-10. Score: 0
  
  If your ENTRYPOINT is `/home/django/start.sh` and you are mounting a volume on `home/django`, that's going to mask the contents of the `/home/django` directory. That means anything included in that directory (and its children) will be inaccessible in the running container. This isn't Kubernetes-specific; this is exactly how the `mount` operation behaves in general.
  
  In general, the solution is to redesign your application to separate the static code from runtime resources, and have the application initialize the runtime directories when it starts up.
  
  If you're not able to modify the application, you may be able to accomplish your goal by using an [init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) to copy the contents of `/home/django` into your volume. That process works by (a) first spawning an init container with the volume mounted at a different location (e.g., `/target`), (b) having the init container run a script that copies the contents of `/home/django` to `/target`, then (c) spawn your regular pod normally.
  
  
  ---
  
  