Harbor database sets wrong permissions.

[DaanSelen]

Hello team, I have noticed that the database sets a permission for itself which it rejects.

I set this up while the container was in a error backoff

Then I delete the pod to let it be recreated by the SS.

KUB-MAST-01:~$ k logs -f harbor-database-0
Defaulted container "database" out of: database, data-permissions-ensurer (init)
init DB, DB version:15
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with this locale configuration:
  provider:    libc
  LC_COLLATE:  en_US.UTF-8
  LC_CTYPE:    en_US.UTF-8
  LC_MESSAGES: C
  LC_MONETARY: C
  LC_NUMERIC:  C
  LC_TIME:     C
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /var/lib/postgresql/data/pgdata/pg15 ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 20
selecting default shared_buffers ... 400kB
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ... 2024-12-12 22:05:47.354 UTC [64] FATAL:  data directory "/var/lib/postgresql/data/pgdata/pg15" has wrong ownership
2024-12-12 22:05:47.354 UTC [64] HINT:  The server must be started by the user that owns the data directory.
child process exited with exit code 1
initdb: removing data directory "/var/lib/postgresql/data/pgdata/pg15"

Then I look at the permissions again.

It now it nobody: docker! Why?

[DaanSelen]

I have rolled out my own PostgreSQL container and it works just fine! So this IS a problem with the chart.

[MinerYang]

Which storageclass are you using? Is it NFS-provisioner? And which Kubernetes distro are been used?

[DaanSelen]

Which storageclass are you using? Is it NFS-provisioner? And which Kubernetes distro are been used?

Bare-Metal (KubeADM) Kubernetes provider.
Using: https://github.com/kubernetes-csi/csi-driver-nfs
With:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-cs-delete
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: nfs.csi.k8s.io
parameters:
  server: 192.168.178.10
  share: /mnt/MassPool/Kubernetes/delete
  # csi.storage.k8s.io/provisioner-secret is only needed for providing mountOptions in DeleteVolume
  # csi.storage.k8s.io/provisioner-secret-name: "mount-options"
  # csi.storage.k8s.io/provisioner-secret-namespace: "default"
reclaimPolicy: Delete
allowVolumeExpansion: True
volumeBindingMode: Immediate
mountOptions:
  - nfsvers=4.1

With a MAPall users to root, so they should be able to do anything. Using TrueNAS Scale.

[m3talstorm]

I'm seeing exactly the same thing, also on TrueNAS, with the same NFS CSI Driver.
Mapall is to a K8-specific user (but has perms to do everything)

[DaanSelen]

I'm seeing exactly the same thing, also on TrueNAS, with the same NFS CSI Driver. Mapall is to a K8-specific user (but has perms to do everything)

Have you managed to fix this? I have just made a PostgreSQL database myself because the default container DOES take the permissions as they are, then just set the database in the HELM to external!

[m3talstorm]

I'm seeing exactly the same thing, also on TrueNAS, with the same NFS CSI Driver. Mapall is to a K8-specific user (but has perms to do everything)

Have you managed to fix this? I have just made a PostgreSQL database myself because the default container DOES take the permissions as they are, then just set the database in the HELM to external!

I haven't, I might have to take the same route as you with an external DB :( I tried the init container + chown posted in another issue, but that didn't help.