@kapa.ai i am trying to deploy airbyte 1.7 via helm getting the following issue with airbyte-db pod

chown: /var/lib/postgresql/data/pgdata: Operation not permitted
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 locale "en_US.utf8".
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/pgdata ... 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
2025-07-22 07:02:55.333 UTC [46] FATAL: data directory "/var/lib/postgresql/data/pgdata" has wrong ownership
2025-07-22 07:02:55.333 UTC [46] HINT: The server must be started by the user that owns the data directory.
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/postgresql/data/pgdata"

The error you are encountering with the Airbyte 1.7 deployment via Helm—specifically,

chown: /var/lib/postgresql/data/pgdata: Operation not permitted

and `FATAL: data directory "/var/lib/postgresql/data/pgdata" has wrong ownership`—is a known issue related to file system permissions and ownership for the PostgreSQL data directory inside the container. This problem typically occurs when the underlying persistent volume (PV) or persistent volume claim (PVC) used by the airbyte-db pod is not allowing the container to set the correct ownership (user: postgres) on the data directory. This is especially common when using certain storage classes, NFS, or running on environments like Docker Desktop, Colima, or WSL2, where file system permissions may not map cleanly between host and container. Key points from the knowledge sources: - The error is seen when the data directory is not owned by the

postgres

user, and the container is unable to change ownership due to file system restrictions. This leads to repeated pod restarts and failed Airbyte deployments. [abctl install fails with postgres permissions error](https://github.com/airbytehq/airbyte/issues/41063) - The issue is also reported in environments like Colima and WSL2, and is not specific to Airbyte 1.7, but rather to how the storage is provisioned and mounted. [Postgres permission issue abctl in Colima](https://github.com/airbytehq/airbyte/issues/54995) - The PostgreSQL server must be started by the user that owns the data directory, and permissions should be

0700

or

0750

for the directory. [failure to connect to airbyte-db postgresql](https://github.com/airbytehq/airbyte/issues/54199) What you can try: 1. Check your storage class and volume permissions: Ensure that the storage class you are using for your PVC supports setting file ownership and permissions. Some NFS or hostPath volumes do not allow containers to change ownership, leading to this error. 2. Set the correct security context: The Airbyte Helm chart allows you to set

fsGroup

and

runAsUser

for the airbyte-db pod. For PostgreSQL, these should typically be set to

70

(the default postgres user/group in the container). Example:

yaml    podSecurityContext:      fsGroup: 70    containerSecurityContext:      runAsUser: 70      runAsGroup: 70

Make sure these are set in your Helm values for the airbyte-db component. [compose/api Error upgrading Airbyte helm chart](https://github.com/airbytehq/airbyte/issues/49843) 3. Delete and recreate the PVC: If the PVC was previously created with the wrong permissions, deleting it (and the associated PV, if possible) and letting Helm recreate it may resolve the issue. Warning: This will delete all data in the database. 4. Try a different storage backend: If you are using Docker Desktop, Colima, or WSL2, consider switching to a different storage backend or running Airbyte on a native Linux environment or a managed Kubernetes service with a supported storage class. If you continue to see this error after checking the above, it is likely an issue with your Kubernetes storage configuration rather than Airbyte itself. The knowledge sources do not provide a one-size-fits-all solution, but the root cause is consistently related to file system permissions and ownership on the database volume. If you need more specific guidance, please provide details about your Kubernetes environment and storage class configuration.