[Bug] Volumes are mounted as nobody:4294967294 which is a problem for rootless containers on K8s

[Cellebyte]

Describe the bug When I create a PVC for a Pod with the following securityContext.

securityContext:
    fsGroup: 1000
    runAsUser: 1000

The pod is not running as a root container. When we now login to the container and try to create a file inside the mounted volume we get the following issue.

bash-4.4$ ls -l /var/data/
total 4
drwxrwxrwx 2 nobody 4294967294 4096 Oct 12 10:09 kpi
bash-4.4$ ls -l /var/data/kpi/
total 0
bash-4.4$ id
uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)
bash-4.4$ cd /var/data/kpi/
bash-4.4$ touch test
touch: cannot touch 'test': Permission denied

This is unfortunate. When we now try to set the supplementalGroup to be gid 4294967294.

securityContext:
    fsGroup: 1000
    runAsUser: 1000
    supplementalGroups: [4294967294]

Kubernetes does not like to set that kind of thing.

Event 23m FailedCreate spec.securityContext.supplementalGroups[0]: Invalid value: 4294967294: must be between 0 and 2147483647

This is unfortunate and blocks us from creating rootless container environments. For context that is what systemd.io says about gids -> https://systemd.io/UIDS-GIDS/

Environment

apiVersion: trident.netapp.io/v1
backendName: ontap-nas-eco
backendUUID: ab622930-fd48-47d2-bcf9-aa1a0e3baec0
config:
  ontap_config:
    aggregate: ""
    autoExportCIDRs:
    - 0.0.0.0/0
    - ::/0
    autoExportPolicy: false
    backendName: ontap-nas-eco
    chapInitiatorSecret: ""
    chapTargetInitiatorSecret: ""
    chapTargetUsername: ""
    chapUsername: ""
    clientCertificate: ""
    clientPrivateKey: secret:ontap-nas-secret
    credentials:
      name: ontap-nas-secret
    dataLIF: 10.23.132.34
    debug: false
    debugTraceFlags: null
    defaults:
      adaptiveQosPolicy: ""
      encryption: "true"
      exportPolicy: trident_qtree_pool_export_policy
      fileSystemType: ext4
      mirroring: "false"
      qosPolicy: ""
      securityStyle: unix
      size: 1G
      snapshotDir: "false"
      snapshotPolicy: none
      snapshotReserve: ""
      spaceAllocation: "true"
      spaceReserve: none
      splitOnClone: "false"
      tieringPolicy: ""
      unixPermissions: '---rwxrwxrwx'
    disableDelete: false
    emptyFlexvolDeferredDeletePeriod: ""
    igroupName: ""
    labels: null
    limitAggregateUsage: ""
    limitVolumeSize: ""
    lunsPerFlexvol: ""
    managementLIF: 10.23.132.35
    nfsMountOptions: ""
    password: secret:ontap-nas-secret
    qtreePruneFlexvolsPeriod: ""
    qtreeQuotaResizePeriod: ""
    qtreesPerFlexvol: ""
    region: ""
    replicationPolicy: ""
    replicationSchedule: ""
    serialNumbers: []
    storage: null
    storageDriverName: ontap-nas-economy
    storagePrefix: t5g_campus_1_refaz_bn
    supportedTopologies: null
    svm: Schiff_SA2
    trustedCACertificate: ""
    usageHeartbeat: ""
    useCHAP: false
    useREST: false
    username: secret:ontap-nas-secret
    version: 1
    zone: ""
configRef: aa7e80ac-4e4e-45d0-b2db-b268ebd060a4
kind: TridentBackend
metadata:
  creationTimestamp: "2022-02-04T16:32:09Z"
  finalizers:
  - trident.netapp.io
  generateName: tbe-
  generation: 2
  name: tbe-6z2nl
  namespace: trident-system
  resourceVersion: "250394073"
  uid: d8949cfd-9562-45b1-a46d-51bca06d2217
online: true
state: online
version: "1"

• Trident version: 22.04.00
• Trident installation flags used: [e.g. -d -n trident --use-custom-yaml]
• Container runtime: containerd 1.6.6
• Kubernetes version: 1.23.8
• OS: Ubuntu 20.04

tbe-6z2nl   ontap-nas-eco     ab622930-fd48-47d2-bcf9-aa1a0e3baec0

• Other:

To Reproduce Steps to reproduce the behavior:

Create a pod or Deployment with above security Context and mount an NFS volume to it. It wont be able to create files.