Error with DB pod failing on init

[jawivana]

Hello im trying to deploy supabase on OKD

chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted
chmod: changing permissions of '/var/run/postgresql': Operation not permitted
The files belonging to this database system will be owned by user "1000720000".
This user must also own the server process.
The database cluster will be initialized with this locale configuration:
provider: libc
LC_COLLATE: C.UTF-8
LC_CTYPE: C.UTF-8
LC_MESSAGES: en_US.UTF-8
LC_MONETARY: en_US.UTF-8
LC_NUMERIC: en_US.UTF-8
LC_TIME: en_US.UTF-8
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... initdb: error: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted

I cant find where the db container is trying to change permissions for the mounted volumes.
Anyone has an Idea what could fix this ? thanks

[gpillon]

Hi!
Are you using persistence and mounted volumes for your database?

If yes, in OKD (and OpenShift in general), containers usually run with a random user ID for security reasons, and they are not allowed to change permissions on mounted volumes unless explicitly permitted. In this case, you might need to assign a more permissive SCC (Security Context Constraint), for example allowing the container to run as root.

I haven't personally tested this with Supabase yet, but you could try assigning the anyuid SCC to your deployment. For example:

oc adm policy add-scc-to-user anyuid -z <your-service-account> #probably "default"

(Replace <your-service-account> with the one used by your pod, or create a specific service account.)

Please be aware that running containers as root should be done carefully for security reasons.

---

Suggestion for the chart maintainers:
It could be a good idea for the Helm chart to automatically detect if it is being deployed on OpenShift/OKD and apply the right SCCs if necessary.

For example, Helm templates can use .Capabilities.APIVersions.Has to detect OpenShift-specific APIs.

Example:

{{- if .Capabilities.APIVersions.Has "security.openshift.io/v1" }}
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: supabase-scc
allowPrivilegedContainer: false
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
users:
  - system:serviceaccount:{{ .Release.Namespace }}:{{ .Values.serviceAccount.name }}
{{- end }}

This way, no manual intervention would be needed from users deploying to OpenShift/OKD.

Hope this helps! 😀