Incompatibility with OCI FSS persistent volumes (.snapshot read-only file system)

[baldo-io]

Name and Version

bitnami/odoo 28.1.1

What architecture are you using?

amd64

What steps will reproduce the bug?

1. In OCI OKE,
2. With this config:
   Storage Class definition:

Name:            oci-fss
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"oci-fss"},"mountOptions":["nolock"],"parameters":{"availabilityDomain":"xxx","compartmentOcid":"xxx","encryptInTransit":"false","mountTargetOcid":"xxx"},"provisioner":"fss.csi.oraclecloud.com"}

Provisioner:           fss.csi.oraclecloud.com
Parameters:            availabilityDomain=xxx,compartmentOcid=xxx,encryptInTransit=false,mountTargetOcid=xxx
AllowVolumeExpansion:  True
MountOptions:
  nolock
ReclaimPolicy:      Delete
VolumeBindingMode:  Immediate
Events:             <none>

And these persistence parameters in values.yml:

persistence:
  enabled: true
  storageClass: "oci-fss"
  accessModes:
    - ReadWriteMany
  size: 2Gi

3. When the odoo container first runs, it will run the bitnami scripts in the /opt/bitnami/scripts/ folder. One action is to ensure that the /bitnami/odoo folder has the correct permissions by running the script

am_i_root && configure_permissions_ownership "$ODOO_VOLUME_DIR" -d "775" -f "664" -u "$ODOO_DAEMON_USER" -g "root"

4. This will throw the error 'Read-only file system' because of the '.snapshot' special folder that the Oracle File Storage Service creates.

odoo odoo 03:55:10.22 INFO  ==> 
odoo odoo 03:55:10.22 INFO  ==> Welcome to the Bitnami odoo container
odoo odoo 03:55:10.22 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
odoo odoo 03:55:10.22 INFO  ==> Did you know there are enterprise versions of the Bitnami catalog? For enhanced secure software supply chain features, unlimited pulls from Docker, LTS support, or application customization, see Bitnami Premium or Tanzu Application Catalog. See https://www.arrow.com/globalecs/na/vendors/bitnami/ for more information.
odoo odoo 03:55:10.22 INFO  ==> 
odoo odoo 03:55:10.23 INFO  ==> Validating settings in POSTGRESQL_CLIENT_* env vars
odoo odoo 03:55:10.32 INFO  ==> Ensuring Odoo directories exist
odoo chmod: changing permissions of '/bitnami/odoo/.snapshot': Read-only file system

5. Using the volume-permission init container cannot solve this.
6. Since changing the bitnami scripts may impact other dependent components, the solution would be to allow a subPath parameter in the deployment.yaml template like this:

          volumeMounts:
            - name: odoo-data
              mountPath: /bitnami/odoo
              {{- if .Values.enableSubPath }}
              subPath: odoo
              {{- end }}

and deal with the mounted path accordingly in the other parts of the chart templates and scripts.

Are you using any custom parameters or values?

diagnosticMode:
  enabled: false
  command:
    - sleep
  args:
    - infinity

image:
  registry: docker.io
  repository: bitnami/odoo
  tag: 18.0.20250105-debian-12-r0
  pullPolicy: IfNotPresent

odooEmail: [email protected]
odooPassword: 'xxx'

smtpHost: "smtp.sendgrid.net"
smtpPort: "465"
smtpUser: "apikey"
smtpPassword: "xxx"

replicaCount: 1
containerPorts:
  http: 8069

resources:
  requests:
    cpu: 1
    memory: 1024Mi
  limits:
    cpu: 2
    memory: 2048Mi

service:
  type: ClusterIP

ingress:
  enabled: true
  ingressClassName: "nginx"
  hostname: xxx.example.com
  path: /
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    cert-manager.io/cluster-issuer: dns-issuer 
  tls: true

persistence:
  enabled: true
  storageClass: "oci-fss"
  accessModes:
    - ReadWriteMany
  size: 2Gi

volumePermissions:
  enabled: true
  resourcesPreset: "nano"
  containerSecurityContext:
    enabled: true
    seLinuxOptions: {}
    runAsUser: 0
    seccompProfile:
      type: "RuntimeDefault"

serviceAccount:
  create: true
postgresql:
  enabled: true
  auth:
    username: bn_odoo
    password: 'xxx'
    database: bitnami_odoo
  architecture: standalone
  primary:
    persistence:
      enabled: true
      size: 50Gi
      storageClass: oci-bv-10

What is the expected behavior?

Either to allow a subPath volumeMount option, or to use the same approach as the initContainers in the same template, that ignores .snapshot and lost+found:

      initContainers:
        {{- if and .Values.volumePermissions.enabled .Values.persistence.enabled }}
        - name: volume-permissions
          image: {{ include "odoo.image" . }}
          imagePullPolicy: {{ .Values.image.pullPolicy | quote }}
          command:
            - /bin/bash
          args:
            - -ec
            - |
              mkdir -p /bitnami/odoo

              find /bitnami/odoo -mindepth 1 -maxdepth 1 -not -name ".snapshot" -not -name "lost+found" | xargs -r chown -R odoo:root

          {{- if .Values.volumePermissions.containerSecurityContext.enabled }}
          securityContext: {{- include "common.compatibility.renderSecurityContext" (dict "secContext" .Values.volumePermissions.containerSecurityContext "context" $) | nindent 12 }}
          {{- end }}
          {{- if .Values.volumePermissions.resources }}
          resources: {{- toYaml .Values.volumePermissions.resources | nindent 12 }}
          {{- else if ne .Values.volumePermissions.resourcesPreset "none" }}
          resources: {{- include "common.resources.preset" (dict "type" .Values.volumePermissions.resourcesPreset) | nindent 12 }}
          {{- end }}
          volumeMounts:
            - name: odoo-data
              mountPath: /bitnami/odoo
        {{- end }}
        {{- if .Values.initContainers }}
        {{- include "common.tplvalues.render" (dict "value" .Values.initContainers "context" $) | nindent 8 }}
        {{- end }}
      {{- end }}

What do you see instead?

An attempt to change the ownership of the .snapshot special folder resulting in an error.

[carrodher]

Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

[baldo-io]

Thank you for your response.
I've changed the storage class to block volume in order to finish the software evaluation.
After that I will try a solution and create a pull request.

[baldo-io]

Pull request created, watingin for review.

[carrodher]

Thank you for opening this issue and submitting the associated Pull Request. Our team will review and provide feedback. Once the PR is merged, the issue will automatically close.

Your contribution is greatly appreciated!