I encountered an issue when initiating a bash script within an Ubuntu container, which led me to include the "bash" command to start the script in a new bash shell. The original command was:
command: ['sh', '-c', '/data/cleaner.sh']
However, I faced a "Permission denied" error, prompting me to modify the command to:
command: ['sh', '-c', 'bash /data/cleaner.sh']
The permission problem became evident in the container's output. The directory listing showed symbolic link details:
root@cleaner-58f6cd657-mzj5w:~# ls -l /data
total 0
lrwxrwxrwx 1 root root 17 Feb 6 18:45 cleaner.sh -> ..data/cleaner.sh
Attempting to execute the script directly resulted in a "Permission denied" error:
root@cleaner-58f6cd657-mzj5w:~# /data/cleaner.sh
bash: /data/cleaner.sh: Permission denied
On the other hand, using the modified command resolved the issue:
root@cleaner-58f6cd657-mzj5w:~# bash /data/cleaner.sh
Get:1 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB]
Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
[...]
Additionally, here is the Kubernetes manifest, including the corrected command:
apiVersion: v1
kind: ConfigMap
metadata:
name: cleaner-config
data:
cleaner.sh: |-
#!/bin/bash
apt-get update
apt-get install -y wget
# some other commands...
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: cleaner
spec:
selector:
matchLabels:
ver: one9
template:
metadata:
labels:
ver: one9
spec:
containers:
- name: kontener
image: ubuntu:latest
command: ['sh','-c', 'bash /data/cleaner.sh']
volumeMounts:
- name: config
mountPath: "/data/"
volumes:
- name: config
configMap:
name: cleaner-config
I'm intrigued why the script didn't start in the sh shell, but it did work in bash.
This is almost certainly the same issue as described in Bash script mounted as configmap with 777 permissions cannot be ran
Where a mounted script is showing as 777 but cannot be executed. Setting the defaultMode to something like 0755 or similar will work (I had this exact same problem on a project I was working on recently)