**Before diving in, I want to acknowledge the research and analysis in this piece is entirely thanks to the outstanding work of Rahul Raju, Senior Maximo Consultant with Naviam, and Murali Shunmugaraja, Cloud and Dev Ops Lead with Yarra Valley Water.
‍

Migrating existing Maximo deployments, specifically transitioning from Maximo 7.6.1 to Maximo Application Suite (MAS) on OpenShift, often presents a critical challenge concerning persistent storage access: the DocLinks volume.
‍

This post details the vital configuration steps required to ensure that Maximo workloads successfully access and interact with existing NetApp NFS volumes by enforcing a fixed Group ID (GID), thereby overcoming standard OpenShift dynamic security constraints.

The Persistence Paradox: Fixed Maximo GIDs vs. Dynamic OpenShift UIDs
‍

‍
In the legacy Maximo 7.6.1 environment, DocLinks volume access was provisioned using fixed Linux User IDs (UIDs) and Group IDs (GIDs), let us say 1000 and 1001 respectively, associated with specific users (wasuser, wasgroup).

However, the MAS 9.0 environment on OpenShift introduces a conflict:

1. Dynamic Allocation: OpenShift dynamically allocates UIDs per namespace, often assigning Maximo processes a 10-digit UID that can vary across deployments.
   ‍

2. Fixed Enforcement: As per the legacy security model, the existing NetApp NFS DocLinks volume enforces access strictly based on the historical, fixed UID-level permissions.
   ‍

Because the containerized Maximo workloads use a random, dynamically assigned UID to access the volume, while the volume expects a fixed UID (specifically 1000), we encounter file ownership mismatches and permission issues when attempting actions like file uploads.
‍

For our existing NetApp volume patterns to function correctly, it is vital that OpenShift communicates to the volume on a fixed UID/GID, such as 1000/1001, instead of using a random UID or the root group. We need a specific fsGroup or Group ID to handle read/write access.
‍

The Solution: Custom SCCs and Maximo Workload Pod Templates

To compel OpenShift to use the required fixed GID 1001 when accessing the DocLinks volume, we leverage OpenShift's Security Context Constraints (SCCs) and apply specific changes to the ManageWorkspaces Custom Resource Definition (CRD) instance.

Step 1: Create a Custom Security Context Constraint (SCC)

First, we create an SCC that mandates the exact fixed GID we need. This resource sets permissions on specific OpenShift controls.

The critical setting ensures that the fsGroup MustRunAs GID 1001:
‍

# SCC Snippet: mas-test-manage-SCC
fsGroup:
 type: MustRunAs
 ranges:
   - min: 1001       # Define the minimum allowed GID
     max: 1001       # Define the maximum allowed GID
supplementalGroups:
 type: RunAsAny
volumes: ['*']
# ... other standard non-privileged security settings ...

We save this definition (e.g., ./mas-test-scc.yaml) and apply it using command

oc apply -f ./mas-test-scc.yaml

‍

Complete example of such yaml file is shared below:
‍

‍

Step 2: Patch SCC to the Service Account

Next, we must bind this custom SCC (mas-test-manage-securitycontext) to the service account responsible for creating the Maximo pods (e.g., ibm-mas-manage-manage-deployment):
‍

Step 3: Update Namespace and Maximo Workload Templates

Two final operational updates are necessary:

1. Namespace Annotation: Update the namespace annotation (oc edit namespace mas-test-manage -o yaml) to explicitly allow the use of the fixed group range, thereby permitting the SCC to function within that namespace
   ‍

2. Workload Pod Templates: We must modify the ManageWorkspaces CRD instance to inject the security context into the podTemplates section. This ensures the container runtime forces the required GID when accessing the DocLinks volume.
   ‍

The securityContext must enforce runAsGroup: 1001 across all relevant Maximo workloads. This fixed GID must be applied to the following workload templates defined in the CRD:

• maxinst
• all
• jms
• mea
• ui
• cron
• report

Example snippet applied to the manageWorkspaces CRD instance:

podTemplates:
   - name: manage-maxinst
     securityContext:
       runAsGroup: 1001         # Enforce the fixed GID
       supplementalGroups:
         - 0
   - name: all
     securityContext:
       runAsGroup: 1001
       supplementalGroups:
         - 0
# ... repeat for jms, mea, cron, ui, report ...
‍

By defining runAsGroup: 1001, every container accessing the DocLinks volume is guaranteed to use the correct historical GID, resolving the long-standing permission mismatch.
‍

‍

Outcome

In summary, once these changes are applied to the OpenShift namespace, all pods deployed within it will inherit and run with the configured GID (e.g., 1001), ensuring consistent security context enforcement across workloads.
‍

‍

Illustrating the Solution Flow: Fixed GID Enforcement for MAS
‍

‍

This structured approach ensures successful migration and continued functionality of DocLinks persistence following the upgrade to Maximo Application Suite 9.0 on OpenShift.
‍

Note:- The security policy at NFS level was updated to define the access restriction at GID (1001) level only. Fixing a constant UID for OpenShift Pods is not recommended, especially when you are planning to host multiple environments on same cluster. Therefore, any restrictions defined at UID level needs to be dropped or to be redefined at GID level.

‍