NooBaa Resources Pick Up Custom SCC Interfering with Intended Functionality of Multicloud Object Gateway (MCG)

Issue

There may be instances when a NooBaa resource(s) picks up the wrong SCCs. The behavior of the NooBaa stack can be as minor as timeouts, or as major as MCG/Object Storage down. This issue may be affecting the environment even if running $ noobaa status or $ oc get backingstore -n <namespace-of-backingstore>, and validating the backingstore is yielding phase Ready. Specific permissions could be denying bucket access/contents/operations. This solution will cover the entire NooBaa stack. If noobaa-db-pg-0 is picking up the wrong SCC, please see the noobaa-db-pg-0 Pod Fails to Start CrashLoopBackOff (CLBO) - "failed container=initialize-database" Wrong SCC solution. Please note that there will be log lines/errors, provided as examples, however, due to this solution covering the entire NooBaa stack, you may not see the specific error being hit. For brevity, please treat this solution as a prerequisite to rule out the incorrect SCC being assigned to a NooBaa resource before opening a Red Hat Support case.

Example:

Code: 500; Error Code: InternalError; Request ID: <omitted>; S3 Extended Request ID: null; Proxy: null), S3 Extended Request ID: null