Application Controller fails with `dynamicClusterDistribution` in namespaced installations

[maksym-iv]

Describe the bug

Deploying the ArgoCD with the dynamicCLusterDistribution enabled, getting the permission error from argocd-application-controller pods:

{"level":"fatal","msg":"unable to get shard due to error updating the sharding config map: error creating shard mapping configmap configmaps is forbidden: User \"system:serviceaccount:argo-hub:argocd-application-controller\" cannot create resource \"configmaps\" in API group \"\" in the namespace \"argo-hub\"","time":"2026-02-27T20:57:19Z"}

Apparently, it is related to the #2743 issue.

Unfortunately role with the rule

  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      - argocd-app-controller-shard-cm
    verbs:
      - get
      - list
      - watch
      - create
      - update

The service account will not be allowed to create a argocd-app-controller-shard-cm ConfigMap - ref, doc

Probably creating the argocd-app-controller-shard-cm configmap from the templates would solve the issue, currently I'm using another workaround:

extraObjects:
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name: argocd-app-controller-shard-cm
      namespace: "{{ .Release.Namespace }}"
    data:
      shardControllerMapping: '[]'

Related helm chart

argo-cd

Helm chart version

v3.3.2

To Reproduce

Deploy with values:

createClusterRoles: false
controller:
  name: application-controller
  replicas: 2
  dynamicClusterDistribution: true

Expected behavior

argocd-application-controller should not encounter the permission error.

Screenshots

No response

Additional context

No response

[vihan-employ]

I am seeing the same issue with

createClusterRole: true
controller:
  dynamicClusterDistribution: true
  clusterRoleRules:
    enabled: true
    rules: 
    - apiGroups:
      - ""
      resources:
      - configmaps
      verbs:
      - create
    - apiGroups:
      - '*'
      resources:
      - '*'
      verbs:
      - '*'
    - nonResourceURLs:
      - '*'
      verbs:
      - '*'

[vihan-employ]

I attempted to use your fix @maksym-iv but it was very unreliable. I got it to work only 20% of the times (after restarting the deployment). Also, if you are tracking your argocd deployment from argocd, it will show up as OOS.

[maksym-iv-ef]

@vihan-employ Wondering what error have you observed.

I do not manage Argo with Argo currently, so probably I'm missing some use-cases.

A guess:
Is OOS issue related to the argocd-app-controller-shard-cm configmap contents?

[vihan-employ]

@maksym-iv-ef The OOS issue is because argo wants that cm to be empty as we are defining in extraObjects, but the controller itself keeps updating it. It's not a huge issue cause we can add an ignore rule in argo for the CM.

Now that I think about it I need to disable auto sync in my argo app and try your fix again.

[maksym-iv-ef]

@vihan-employ That's what I've thought.

I don't manage argo with argo so I don't face the issue, however another workaround would be good old kubectl apply -f configmap.yaml before installing Argo.
This of course does not ideally falls under the GitOps process.