Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: If gid is configured in Pod's securityContext.fsGroup, csi inline will panic. log: E0320 16:50:59. ] Operation for """ ("-ae1b-4b5c-be91-")" failed. No retries permitted until 2020-03-20 16:51:31. +0800 CST m=+. (durationBeforeRetry 32s). Error: "recovered from panic "runtime error: invalid memory address or nil pointer dereference". (err=<nil) Call stack:ngoroutine [running]:(0xc001497e70)n +0xb5npanic(0x3b713e0, 0x7bd2050)n +0x1b5(csiMountMgr).applyFSGroup(0xc0005372c0, 0xc001a2f100, 0x4, 0xc00205ed70, 0x44, 0x0)n +0x64(csiMountMgr).SetUpAt(0xc0005372c0, 0xc000b6cb80, 0x78, 0xc00205ed70, 0x0, 0x0, 0x0)n +0x1180(csiMountMgr).SetUp(0xc0005372c0, 0xc00205ed70, 0x0, 0x0, 0x0)n +0x4d(operationGenerator).GenerateMountVolumeFunc.func1(0x8, 0x453f9f8, 0xc001497e70, 0xc0025ba750)n +0x4a4(GeneratedOperations).Run(0xc0009742a0, 0x452f628, 0xc000d56480, 0xc00135a050, 0x45)n +0xaf(nestedPendingOperations).Run.func1(0xc000d56480, 0xc00135a050, 0x45, 0xc001106d50, 0x24, 0xc0009742a0, 0x0, 0x0, 0x0, 0x0)n +0xcbncreated by (*nestedPendingOperations).Runn +0x378n" code: If using inline volume, c.spec.PersistentVolume will be nil What you expected to happen: fsGroup is successfully applied Environment: Kubernetes version (use ): 1.16.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig sig/storage
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig/storage Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
ran into this bug recently on v1.18, and I don't see anything that would fix this issue on later releases either. /reopen /lifecycle freeze /assign
Reopened this issue. <detailsIn response to : ran into this bug recently on v1.18, and I don't see anything that would fix this issue on later releases either. /reopen /lifecycle freeze /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
/lifecycle frozen
I tested this scenario with the hostpath driver on k8s 1.24 (built from master) on a local VM using a slightly modified version of the examples/csi-app- spec ( fsGroup and fsType): And this does not panic kubelet It does not panic because of this check: Which was in However, I do believe we can and should support fsgroup for CSI inline volumes. Instead of checking the PV spec (which is not set for inline volumes) we could pass the directly into , which will be RWO for inline volumes.
Sorry, it was not obvious that the panic was already fixed when I first looked at this. Re-purposing this bug to address the issue that fsgroup still does not get applied for inline volumes. /retitle CSI inline volumes do not apply fsGroup
THX, also link to this
/retitle CSI inline volumes should support fsGroup

Related discussion:
text: }, want: true, }, <ins> { name: "driverPolicy is ReadWriteOnceWithFSTypeFSGroupPolicy with CSI inline volume", args: args{ fsGroup:      new(int64), fsType:       "ext4", driverPolicy: storage.ReadWriteOnceWithFSTypeFSGroupPolicy, }, fields: fields{ spec: volume.NewSpecFromVolume(&api.Volume{ VolumeSource: api.VolumeSource{ CSI: &api.CSIVolumeSource{ Driver: testDriver, }, }, }), }, want: true, }, </ins> } for _, tt := range tests {