starting container process caused: exec: "/app/code/start.sh": permission denied: unknown

[rmdes]

I have followed other python app idea for now to try to package Tanzawa
my build seem to be ok locally but when I push & install with cloudron cli
I'm getting starting container process caused: Bad Field: (HTTP code 400) unexpected - OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/app/code/start.sh": permission denied: unknown

It seems to be a permission error because start . sh is where it is expected inside the container
I tried with /app/pkg/start.sh and /app/code/start.sh

I have my Dockerfile & start . sh here : https://paste.armada.digital/ogoxofadex.yaml
someone from the app makers can have a look ?

• by default tanzawa use sqlite3, i'm not trying to change that for a first package
• only addon is localstorage, to have backup /app/data (cloudron manifest)
• I have doubts about the path I have to use launch the python server (see end of the start . sh)
• there is a createsuperuser python3 command to do manually, I'm okay with that for a first version
• it seems my .env.sample is not being carried out because when I go inside the cloudron container (before this error blocked everything) the .env file was always empty

[nebulon]

@rmdes so the start.sh need to have the exec bit set. You can either do this in the app package folder itself and commit this to git, like on your laptop do chmod +x start.sh or you do this in the Dockerfile. Both works, however doing it in the Dockerfile adds another rather unnecessary image layer.

[timconsidine]

@rmdes I use a CHOWN statement to cloudron:cloudron towards the end of my Dockerfile

Trying to find an example but git.cloudron.io is not responding at the moment.

[timconsidine]

@rmdes try something like this

RUN chown -R cloudron:cloudron /app/code

Not guaranteed to fix but no harm trying

EDIT : Maybe move the CHOWN commands out of start.sh into the Dockerfile ?

[timconsidine]

@rmdes I don't understand this

COPY start.sh /app/pkg/start.sh
CMD [ "/app/code/start.sh" ]

They're different locations.

[rmdes]

@timconsidine Yes this was an error when I did the pastebin
because I tried both ways, using /app/pkg/start sh
and /app/code/start sh

[timconsidine]

@rmdes ah ok

[rmdes]

@timconsidine gonna try to do this

[rmdes]

Doing the install to cloudron now, let's see if it boots

[rmdes]

This is where I am now : https://paste.armada.digital/umomimefek.yaml

[timconsidine]

@rmdes but it doesn't boot ?

[timconsidine]

@rmdes this may be an ignorant question : I am not a dev and not that familiar with python
In your Dockerfile you are using virtualenv
I understand this can be important in a system where other processes and apps are running.
But conceptually a Docker app is isolated
So virtualenv actually needed ?
Might it be adding complexity ?

[nebulon]

@rmdes so the start.sh need to have the exec bit set. You can either do this in the app package folder itself and commit this to git, like on your laptop do chmod +x start.sh or you do this in the Dockerfile. Both works, however doing it in the Dockerfile adds another rather unnecessary image layer.

[rmdes]

@timconsidine No worries, me neither

Actually it's quite common see other apps, but I'm not sure about the logic to do it in start sh or Dockerfile, which is the best I mean..

Taiga : https://git.cloudron.io/cloudron/taiga-app/-/blob/master/start.sh

Other python apps : https://git.cloudron.io/cloudron?filter=python

edit : outside cloudron context, I have seen virtualenv or pyenv used in a lot of dockerfiles for python project, so I'm quite confident starting from the original Dockerfile is the way to go

[rmdes]

@nebulon Now that you say it, of course, it's logical that was missing !!
Thank you

[rmdes]

@timconsidine the idea with docker is precisely that, you start from a base image, here provided by cloudron base and from there you build the environnement you need for that particular app, here, based on the requirements.txt like you would do if you wanted to run the app in a virtual machine/docker/container or simply running in your laptop locally, you want this feature so that you can get exactly the required environnement loaded in the docker container, just to run what the original code require, that's how I understand it, but no worries I'm not a dev here, just a passionate learner

[timconsidine]

@nebulon said in starting container process caused: exec: "/app/code/start.sh": permission denied: unknown:

Both works, however doing it in the Dockerfile adds another rather unnecessary image layer.

That's very interesting, from perspective of someone learning to package.
Thank you

[rmdes]

I went chmoding the file locally, now it's rebuilding the container, next is to push it to docker hub
then cloudron install

[timconsidine]

@rmdes I can't stand the suspense

[rmdes]

Alright, it's running!

Now I have to take care of env file not being taken into account
and the secret being generated in the Dockerfile not being stored in the .env.sample
hence the app boot, but screaming for an .env & appropriate secret

[timconsidine]

@rmdes congratulations !