Hi Andy,
This is actually an Azure storage infrastructure constraint rather than a traditional external database connectivity issue (like Db2 or SQL Server).
The rhm-data-service pod (Red Hat Marketplace data service) utilizes a local, file-backed SQLite/embedded metadata store (.info.yaml) to cache license entitlement keys and airgap state data. During the pod's initialization lifecycle, the internal Go binary attempts to execute a standard Linux chmod operation to secure permissions on that folder structure. [2]
If your Single Node OpenShift (SNO) cluster is dynamically provisioning persistent volumes using the azurefile-csi (Azure Files via SMB/CIFS) storage class, this execution fails. By default, SMB layers mounted into unprivileged, non-root containers do not support standard POSIX chmod/chown semantics, throwing the exact operation not permitted crash loop you are experiencing.
Depending on whether you are running a manual install or using an automated framework, here are the paths to clear the error:
Solution Path A: If Using Automated Helper Utilities (mas-cli)
If you are leveraging the automated
IBM Maximo Application Suite CLI utility (
mas-cli engine) to dynamically spin up your deployment components, the automated installer attempts to match workloads with appropriate defaults.
[3, 4] You can explicitly override storage providers globally during non-interactive installations by supplying flags to separate file systems from block devices. Instead of feeding azurefile-csi universally, explicitly target the block layer for read-write-once (RWO) operator caches: [1, 3, 5]
# Force operational metrics to rely strictly on Azure Disk Block Storage
--storage-rwo managed-csi \
--storage-rwx azurefile-csi
This maps the data service pods to an underlying block architecture that natively permits file modifications.
Solution Path B: Direct azurefile-csi StorageClass Customization
If you prefer to continue backing your operators with Azure Files, you must configure the storage provisioner to mask and bypass remote container permission enforcement.
⚠️ Disclaimer: Please validate this modification in a sandbox or staging context before applying it universally to standard multi-node production storage manifests. Bypassing volume permission validations entirely (noperm) can alter security expectations depending on tenant multi-occupancy structures.
To speed up execution, you can run this single-line patch script to inject the required noperm parameter into your dynamic cluster configuration:
# 1. Patch the storage class with required CIFS execution overrides
oc patch storageclass azurefile-csi --type='json' -p='[{"op": "add", "path": "/mountOptions", "value": ["noperm", "mfsymlinks", "actimeo=30"]}]'
# 2. Cycle the crashing metrics collector pod to bind with new mount policies
oc delete pod -l app=rhm-data-service -n ibm-software-central
What this script alters under the hood:
The JSON patch modifies your standard azurefile-csi manifest definition directly:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi
provisioner: ://azure.com
mountOptions:
- noperm # Tells the mount layer to skip remote client chmod/chown verification
- mfsymlinks # Retains support for Unix symbolic links on the file share
- actimeo=30 # Adjusts attribute caching timers for optimized cluster communication
Once the pod recycles with the noperm mount rule, the Go application will complete its internal file check operations successfully and allow the rest of your MAS operator platform chain to deploy seamlessly.
Let us know if dropping in the automation flags or running the storage class patch clears the block on your Azure SNO node!
Let me know if you would like to expand on specific namespace contexts for the metrics operator or require additional scripts for verification!
Please see the sources used to answer your question
------------------------------
[Fredrick] [Ndwaru]
[Perpetual Ignition]
------------------------------