Cannot chmod file on Openshift online v3 : Operation not permitted

Question

I am migrating a Django application from Openshift v2 to v3 (In case you don't know, RedHat is shutting down v2 on September 30th, see: https://blog.openshift.com/migrate-to-v3-v2-eol/)

So, I am following this blog post to help me: https://blog.openshift.com/migrating-django-applications-openshift-3/ . I am new to all these Docker / Kubernetes concepts the new version is build upon.

I was able to make some progress : I managed to get a successful build of my app. Yet it crashes at deployment time:

---> Running application from script (app.sh) ... /usr/libexec/s2i/run: line 42: /opt/app-root/src/app.sh: Permission denied

Indeed, app.sh has lost its x permission. I log into the failing container as debug and see it:

> oc debug dc/<my app>
> (app-root)sh-4.2$ ls -l /opt/app-root/src/app.sh 
-rw-rw-r--. 1 default root 127 Sep  6 21:20 /opt/app-root/src/app.sh 

The blog posts states "Ensure that the app.sh file is executable by running chmod +x app.sh.", which I did on my local repo. Whatever, I want to do it again directly in the pod, but it doesn't work:

(app-root)sh-4.2$ chmod +x /opt/app-root/src/app.sh                             
chmod: changing permissions of ‘/opt/app-root/src/app.sh’: Operation not permitted

So, how can I set the x permission to app.sh ? Thank you

Answer 1

Without looking into more details, any S2I builder image will gladly use your custom supplied run script to start the application in an alternative way.

Create .s2i/bin/ (mind the dot) in your source code directory, place the run script into it and rebuild the app in OpenShift - it will automatically use your custom run script upon deployment.

This is the preferred way of starting applications using custom commands in OpenShift.

Regarding your immediate problem, there is a very simple reason why you can not change the permissions of the script: you were trying to modify the permissions in the deployed pod, and not the builder pod. Deployed pods run using different UIDs, usually somewhere in the range of 100000000, and definitely do not match the file ownership as generated by the build. Hence permission denied.

The root cause of your problem (app.sh losing executable permissions) must be in the way the build process installs those files, and indeed looking at the /usr/libexec/s2i/assemble script in the base image does seem to reveal the culprit. The last two lines are:

# set permissions for any installed artifacts
fix-permissions /opt/app-root

If you wanted to change this part of the build instead of using a custom run script, I suggest you then create .s2i/bin/assemble in your project's source code and make it look sort of like this:

#!/bin/bash
echo "Running stock build:"
${STI_SCRIPTS_PATH}/assemble
echo "Fixing the mess:"
chmod 755 /opt/app-root/src/app.sh

This will fix whatever the stock build process does to file permissions, and will do it using the same UID as the rest of the build, so file ownership shouldn't be an issue.

Answer 2

as I stumbled upon this issue myself I've found a way to resolve it. You have to make your file app.sh executable and push it in your repo as such. If git does not track this modification as it did for me, you have to use: git update-index --chmod=+x app.sh for it to work.