ISCSI LUN persists after PV deletion

[alexcyber]

Bug: CSI DeleteVolume/Destroy returns success but LUN is not deleted on QNAP NAS

Environment

Component	Version
QNAP CSI (trident-main)	qnapsystem/qnap-csi:v1.6.0
QNAP CSI backend sidecar	qnapsystem/qnap-csi-backend-qts-sidecar:v1.6.0
csi-provisioner	registry.k8s.io/sig-storage/csi-provisioner:v4.0.0
csi-attacher	registry.k8s.io/sig-storage/csi-attacher:v4.5.0
Kubernetes	v1.34.3+k3s1
QNAP NAS model	TS-453Be
Storage driver	qnap-nas (iSCSI block)

StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: qnap-auto-delete
provisioner: csi.trident.qnap.io
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
parameters:
  fsType: ext4
  replacementTimeout: "120"
  selector: performance=general

TridentBackendConfig

apiVersion: trident.qnap.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-qts
  namespace: qnap
spec:
  backendName: qts
  credentials:
    name: backend-qts-secret
  debugTraceFlags:
    method: true
  networkInterfaces:
    - 'Adapter 2 (VLAN: 23)'
  storage:
    - labels:
        performance: general
      serviceLevel: pool1
  storageDriverName: qnap-nas
  version: 1

Steps to Reproduce

1. Create a PVC using the qnap-auto-delete StorageClass (reclaimPolicy: Delete)
2. Bind it to a pod (StatefulSet in this case), confirm the LUN is provisioned on the QNAP
3. Delete the pod/StatefulSet
4. Delete the PVC

Expected Behavior

The LUN on the QNAP NAS should be removed after the PVC is deleted and the CSI DeleteVolume call completes.

Actual Behavior

The CSI DeleteVolume and Destroy calls return successfully (no errors in logs), but the LUN remains on the QNAP NAS in "Ready" state. It is not removed or in a "Removing" state — it simply persists as if the delete never happened.

The Kubernetes side is fully clean (PVC, PV, TridentVolume CRD all removed), but the iSCSI LUN on the NAS remains and must be manually deleted via the QNAP web UI.

Trident Controller Logs

Volume creation (successful):

time="2026-02-16T06:35:08Z" level=debug msg="Attempting volume create." backend=qts volume=pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 volumeInternal=trident-pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 workflow="volume=create"
time="2026-02-16T06:35:29Z" level=debug msg="<<<< Create" Method=Create Type=QTSDriver VolName=trident-pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5

Volume unpublish (successful):

time="2026-02-16T06:37:10Z" level=debug msg=">>>>>> Orchestrator#deleteVolumePublication" nodeName=k1 volumeName=pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 workflow="controller=unpublish"

Volume delete/destroy (returns success, but LUN persists on NAS):

time="2026-02-16T06:40:54Z" level=debug msg="GRPC call: /csi.v1.Controller/DeleteVolume" Request="GRPC request: volume_id:\"pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5\" "
time="2026-02-16T06:40:54Z" level=debug msg=AddVolumeTransaction name=pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 op=deleteVolume workflow="volume=delete"
time="2026-02-16T06:40:54Z" level=debug msg="Backend#RemoveVolume" backend=qts volume=pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 volumeInternal=trident-pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 workflow="volume=delete"
time="2026-02-16T06:40:54Z" level=debug msg=">>>> Destroy" Internal ID=3bb7a746-edb3-41f4-b3b6-6d2a46409124 Method=Destroy Name=trident-pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 Type=QTSDriver workflow="volume=delete"
time="2026-02-16T06:40:54Z" level=debug msg="<<<< Destroy" Internal ID=3bb7a746-edb3-41f4-b3b6-6d2a46409124 Method=Destroy Name=trident-pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 Type=QTSDriver workflow="volume=delete"

Note: The Destroy call returns immediately with no error, yet the LUN trident-pvc-b3c20a22-6a4f-4420-8ee8-d9780c6ea4f5 remains in "Ready" state on the QNAP NAS.

Additional Context

This issue was also observed with reclaimPolicy: Retain volumes where PVs were deleted directly — TridentVolume CRDs would become orphaned and the backing LUNs were never cleaned up. The Destroy call appears to return success from the QNAP API without actually performing the deletion.

[Shanna-chen]

Hi @alexcyber ,

Thank you for the report and for providing the logs. We have investigated this issue but have been unable to reproduce it in our internal testing environment.

Our Test Environment & Results
We attempted to replicate the behavior using both iSCSI (block) and SMB (file) protocols with QNAP CSI v1.6.0. In our tests:

• iSCSI: Volume creation took ~20s, and deletion took 7–69s. Both the LUN and Target were successfully removed from the NAS.
• SMB: Deletion was near-instant, and the shared folders were correctly cleaned up.

Environment used for reproduction:

• NAS: QTS 5.2.6
• CSI Plugin: v1.6.0
• K8s: v1.35.0 (kubeadm)

To help us investigate further, could you please:
Verify the current firmware version of your TS-453Be.
Check the System Logs on the QNAP NAS (via QuLog Center) around the time of the DeleteVolume call to see if there are any hidden errors (e.g., "LUN is in use" or "Permission denied").

Professional Support:
If the issue persists despite using the latest firmware, we recommend submitting a formal support ticket via the Helpdesk app on your QNAP NAS. Our technical support team can securely access your logs and environment to pinpoint why the API is returning a false success.

We will keep this issue open for further discussion if you have more findings.