QNAP CSI publishes invalid iSCSI portal metadata (p1: "", p2: <ip>) for new and existing volumes even with networkInterfaces configured

[kai-wegner]

Steps to reproduce

0. Add multiple NICs/IPs to QNAP, either as virtual-switch or dedicated network-interface
   • optional - configure only one (the desired) interface as portal on existing LUN
1. Configure a QNAP backend using:
   • storageDriverName: qnap-nas
   • dedicated storage IP 192.168.2.50
   • dedicated interface selection:

       networkInterfaces:
         - "Adapter 4"

2. Restart trident-controller
3. Verify the runtime backend reflects the config:

  networkInterfaces:
  - Adapter 4

4. Create a brand new PVC and a Pod using that PVC
5. Inspect the resulting VolumeAttachment

Expected behavior

The published iSCSI portal metadata should contain only valid portals.

For a single intended storage interface/IP, we would expect something like:

  iscsiTargetPortalCount: "1"
  p1: "192.168.2.50"

At minimum, the driver should never publish an empty portal entry.

Actual behavior

The driver publishes invalid portal metadata like:

  iscsiTargetPortalCount: "2"
  p1: ""
  p2: "192.168.2.50"

This happens for:

• existing volumes
• volumes re-published to another node
• newly created PVCs after networkInterfaces is configured

Relevant logs

Node-side staging logs show:

  Failed to discover targets
  iscsiadm: Cannot resolve host . getaddrinfo error: [Name does not resolve]
  iscsiadm: No portals found
  portal=":3260"

and:

  Failed to add portal  to self-healing map; err: portal value cannot be empty

Environment

• Kubernetes: v1.33.3
• Talos Linux: v1.12.6
• Kernel: 6.18.18-talos
• Container runtime: containerd://2.1.6

QNAP CSI / Trident

• qnapsystem/qnap-csi:v1.6.0
• qnapsystem/qnap-csi-backend-qts-sidecar:v1.6.0
• qnapsystem/qnap-csi-operator:v1.6.0
• reported orchestrator version: v1.06.0

Backend

• storageDriverName: qnap-nas
• storageAddress: 192.168.2.50
• networkInterfaces: ["Adapter 4"]

Additional notes

• networkInterfaces is accepted by the backend config
• after restarting trident-controller, the runtime backend also shows:

    networkInterfaces:
    - Adapter 4

• despite that, new VolumeAttachments still contain:

    p1: ""
    p2: "192.168.2.50"

This suggests the problem is not only stale state from older volumes.

Questions

• Is this a known issue?
• Should networkInterfaces restrict published iSCSI portals to the selected interface only?
• Should the driver ignore empty/disabled portal entries returned by the backend?
• Is this behavior specific to qnap-nas?
• Would qnap-iscsi behave differently?
• What happens if multiple network-interfaces are configured on iSCSI-LUNs (QNAP) while having only one networkInterface configured? (Multi-Path or Single-Path?)

[Shanna-chen]

Hi @kai-wegner
Thanks for the detailed report and clear reproduction steps — this is very helpful.

Confirming this is a known issue on our side. The networkInterfaces filter is not being applied correctly when publishing the iSCSI portal metadata, which is why you're seeing the empty entry alongside the valid portal. We've scheduled this to be addressed in a future release and will update this issue once a fix is available.
Appreciate you flagging it — we'll keep you posted.