[bitnami/odoo] chown: changing ownership of '/bitnami/odoo': Operation not permitted when booting

jean-francoismougnot commented 2 months ago

Name and Version

bitnami/odoo 17.0.20240705

What architecture are you using?

None

What steps will reproduce the bug?

I'm currently working on our staging eks cluster to deploy an installation of odoo, using both chart and container you provide and thank you for this awesome work ! We use aws efs storage class in order to use ReadWriteMany volume mounts between every replicas of Odoo and job to install web_entreprise (and other addons) we pay for, triggered via post-install, post-upgrade helm hooks.
the storage class is as follow StorageClass in our stg cluster as follow :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs
provisioner: efs.csi.aws.com
parameters:
  directoryPerms: '700'
  provisioningMode: efs-ap
reclaimPolicy: Delete
volumeBindingMode: Immediate

CSIDriver:

{
  "kind": "CSIDriver",
  "apiVersion": "storage.k8s.io/v1",
  "metadata": {
    "name": "efs.csi.aws.com",
    "annotations": {
      "helm.sh/hook": "pre-install, pre-upgrade",
      "helm.sh/hook-delete-policy": "before-hook-creation",
      "helm.sh/resource-policy": "keep",
  },
  "spec": {
    "attachRequired": false,
    "podInfoOnMount": false,
    "volumeLifecycleModes": [
      "Persistent"
    ],
    "storageCapacity": false,
    "fsGroupPolicy": "ReadWriteOnceWithFSType",
    "requiresRepublish": false,
    "seLinuxMount": false
  }
}

I've tried using pretty much every default securityContexts and according combinations for both container and pod provided as default helm values. I've tried with odoo.volumePermissions.enabled = true as described here https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-helm-chart-issues/#permission-errors-when-enabling-persistence I've tried with every security policies disabled too, just to see. and as said some combinations.
rolling update of the deployment with every possible configuration always end up with the follogin errors :

odoo 13:29:40.71 INFO  ==>
odoo 13:29:40.71 INFO  ==> Welcome to the Bitnami odoo container
odoo 13:29:40.72 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
odoo 13:29:40.72 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
odoo 13:29:40.72 INFO  ==> Upgrade to Tanzu Application Catalog for production environments to access custom-configured and pre-packaged software components. Gain enhanced features, including Software Bill of Materials (SBOM), CVE scan result reports, and VEX documents. To learn more, visit https://bitnami.com/enterprise
odoo 13:29:40.72 INFO  ==>
odoo 13:29:40.73 INFO  ==> Validating settings in POSTGRESQL_CLIENT_* env vars
odoo 13:29:40.73 INFO  ==> Trying to connect to the database server
odoo 13:29:40.79 INFO  ==> Creating database user odoo_stg
odoo 13:29:40.83 INFO  ==> Creating database bitnami_odoo
odoo 13:29:40.94 INFO  ==> Ensuring Odoo directories exist
chown: changing ownership of '/bitnami/odoo': Operation not permitted

It's seems that the volume-permissions initContainer succesfully chown where the .sh script run in the entrypoint of the container always fail to do so.

Are you using any custom parameters or values?

default securityContexts ones.

Actual setup :

  volumePermissions:
    enabled: true
  containerSecurityContext:
    capabilities:
      drop: []

Combinations tested:

  volumePermissions:
    enabled: true
  podSecurityContext:
    enabled: false
  containerSecurityContext:
    capabilities:
      drop: []
    allowPrivilegeEscalation: true

  podSecurityContext:
    enabled: false
  containerSecurityContext:
    enabled: false

and a mix of all these.

What is the expected behavior?

Healthy running container kind like this in localhost :

odoo 13:36:37.16 INFO  ==> 
odoo 13:36:37.16 INFO  ==> Welcome to the Bitnami odoo container
odoo 13:36:37.16 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
odoo 13:36:37.16 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
odoo 13:36:37.16 INFO  ==> Upgrade to Tanzu Application Catalog for production environments to access custom-configured and pre-packaged software components. Gain enhanced features, including Software Bill of Materials (SBOM), CVE scan result reports, and VEX documents. To learn more, visit https://bitnami.com/enterprise
odoo 13:36:37.16 INFO  ==> 
odoo 13:36:37.17 INFO  ==> Validating settings in POSTGRESQL_CLIENT_* env vars
odoo 13:36:37.18 INFO  ==> Restoring persisted Odoo installation
odoo 13:36:37.19 INFO  ==> Trying to connect to the database server
odoo 13:36:37.21 INFO  ==> Updating modules

odoo 13:36:50.63 INFO  ==> ** Odoo setup finished! **
odoo 13:36:50.64 INFO  ==> ** Starting Odoo **
/opt/bitnami/odoo/bin/odoo:4: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
  __import__('pkg_resources').run_script('odoo==17.0.post20240705', 'odoo')
2024-09-06 13:36:50,929 1 INFO ? odoo: Odoo version 17.0-20240705 
2024-09-06 13:36:50,929 1 INFO ? odoo: Using configuration file at /opt/bitnami/odoo/conf/odoo.conf 
2024-09-06 13:36:50,929 1 INFO ? odoo: addons paths: ['/opt/bitnami/odoo/lib/odoo-17.0.post20240705-py3.11.egg/odoo/addons', '/bitnami/odoo/data/addons/17.0', '/bitnami/odoo/addons'] 
2024-09-06 13:36:50,929 1 INFO ? odoo: database: bn_odoo@odoo-postgresql:5432 
2024-09-06 13:36:50,983 1 INFO ? odoo.addons.base.models.ir_actions_report: Will use the Wkhtmltopdf binary at /usr/local/bin/wkhtmltopdf 
2024-09-06 13:36:51,055 1 INFO ? odoo.service.server: HTTP service (werkzeug) running on odoo-f6d887c96-rfkk6:8069 
2024-09-06 13:36:51,062 1 INFO bitnami_odoo odoo.modules.loading: loading 1 modules... 
2024-09-06 13:36:51,065 1 INFO bitnami_odoo odoo.modules.loading: 1 modules loaded in 0.00s, 0 queries (+0 extra) 
2024-09-06 13:36:51,069 1 INFO bitnami_odoo odoo.modules.loading: loading 13 modules...

What do you see instead?

100% chown: changing ownership of '/bitnami/odoo': Operation not permitted

odoo 13:29:40.71 INFO  ==>
odoo 13:29:40.71 INFO  ==> Welcome to the Bitnami odoo container
odoo 13:29:40.72 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
odoo 13:29:40.72 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
odoo 13:29:40.72 INFO  ==> Upgrade to Tanzu Application Catalog for production environments to access custom-configured and pre-packaged software components. Gain enhanced features, including Software Bill of Materials (SBOM), CVE scan result reports, and VEX documents. To learn more, visit https://bitnami.com/enterprise
odoo 13:29:40.72 INFO  ==>
odoo 13:29:40.73 INFO  ==> Validating settings in POSTGRESQL_CLIENT_* env vars
odoo 13:29:40.73 INFO  ==> Trying to connect to the database server
odoo 13:29:40.79 INFO  ==> Creating database user odoo_stg
odoo 13:29:40.83 INFO  ==> Creating database bitnami_odoo
odoo 13:29:40.94 INFO  ==> Ensuring Odoo directories exist
chown: changing ownership of '/bitnami/odoo': Operation not permitted

Additional information

is there a runtime difference between the chown done in volume-permission in initContainer (volumePermissions.enabled:true) and the one done in the entrypoint of the runtime container ? i'm struggling to get what's could be the diff

I'm not sure if i'm missing something and would love to have your opinion on this one. Do you manage to properly mount replicated odoo pods with a single RWX PV ?

I'm starting to dig around efs csi and found this one which looks a lot like my actual situation. Do you think it could be my culprit ?

As a workaround, do you think it'd be possible to bypass / deactivate the chown in entrypoint of odoo container made in the entrypoint scripts ?

Do you have any other ideas / recomendations for me maybe ?

carrodher commented 2 months ago

Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.

For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:

These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.

jean-francoismougnot commented 2 months ago

Thank you for your time and response ! I'm well aware of these knowledge and good practices sharing :) That's even why I always go to use your containers and charts, awesome work !

But if i understand well, that's precisely the oposite for Odoo.

See it here configuring permission to odoo deamon to be part of root group: https://github.com/bitnami/containers/blob/main/bitnami/odoo/17/debian-12/rootfs/opt/bitnami/scripts/odoo/postunpack.sh#L43

or here trying to chown: https://github.com/bitnami/containers/blob/48b7c41bdc3738cbd8c6234fa3274ebe0eb84c07/bitnami/solr/8/debian-12/prebuildfs/opt/bitnami/scripts/libfs.sh#L22

chown/chgrp here: https://github.com/bitnami/containers/blob/48b7c41bdc3738cbd8c6234fa3274ebe0eb84c07/bitnami/solr/8/debian-12/prebuildfs/opt/bitnami/scripts/libfs.sh#L137

the bitnami/odoo chart helm also default to run it as root:root as documented here : https://github.com/bitnami/charts/tree/main/bitnami/odoo

Screenshot 2024-09-09 at 11 32 07

github-actions[bot] commented 1 month ago

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

github-actions[bot] commented 1 month ago

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

muhammadarslan commented 2 weeks ago

Did this issue get resolve? what was the workaround? facing this problem as well, where can't attach the efs volume with eks pod

bitnami / charts