ISCSI-Ziele verbinden nicht – QuTS hero iSCSI-Fehler: Initiator-ACLs nicht in SCST geschrieben (Broken pipe, ESXi kann nicht verbinden)

Ich habe derzeit ein Problem bei der Verbindung zum ISCSI Target auf meinem QNAP NAS TS-H973ax.

Dieses Problem besteht seit einem Firmware-Update im November 2025.

QuTS hero iSCSI-Fehler: Initiator-ACLs werden nicht in SCST geschrieben (Broken pipe, ESXi kann keine Verbindung herstellen)

Ich poste das hier, falls andere auf das gleiche Problem gestoßen sind, und um herauszufinden, ob jemand (oder QNAP-Mitarbeiter) bestätigen kann, ob dies ein bekannter QuTS hero-Bug ist.
Hardware / Software

NAS: QNAP TS‑h973AX
OS: QuTS hero (getestet mit mehreren 5.x-Versionen und h6.0.0.3397 Beta)
iSCSI Target Stack: SCST
Initiatoren: VMware ESXi (läuft in VMware Workstation – Laborumgebung)
Netzwerk: 2,5GbE, keine Firewall zwischen Initiator und NAS

Problembeschreibung
Der iSCSI-Dienst startet und Targets werden im GUI als „Bereit“ angezeigt, aber ESXi kann keine Verbindung zu einem iSCSI-Target herstellen.
Nach umfangreicher Fehlersuche scheint das Hauptproblem zu sein, dass Initiator-ACLs nie in SCST geschrieben werden, selbst wenn Initiatoren explizit im GUI definiert sind. Die ACL-Datei fällt immer auf den Standard-Pseudo-Initiator zurück.
Als Folge:

Es werden keine iSCSI-Sitzungen aufgebaut
ESXi-Scans werden ohne Fehler abgeschlossen, aber es erscheinen keine Geräte
iSCSI ist faktisch unbenutzbar

Hauptsymptom
Die ACL-Datei enthält immer nur die Standard-Policy, nie echte Initiatoren:

cat /etc/config/hero_iscsi_scst_init_lun_acl.json
“initiator”:{
“0”:{
“name”:“iqn.2004-04.com.qnap:all:iscsi.default.ffffff”,
“alias”:“Default Policy”
}
}

Selbst nach:

Löschen aller Initiatoren
Neuanlage von Initiatoren mit expliziten ESXi-IQNs
Regenerierung der ACLs
Neustart von iSCSI
Firmware-Upgrade
Firmware-Downgrade

Tauchen die ESXi-IQNs nie in der Datei auf.

Relevante Fehler
Während iSCSI-Neustarts erscheint wiederholt Folgendes:
event_conn:965:ERROR: write error Broken pipe

Das deutet darauf hin, dass der QNAP iSCSI-Managementdienst nicht mit dem SCST-Kontrollsocket kommunizieren kann, sodass ACL-Updates nie übernommen werden.
Früher bei der Fehlersuche hat SCST außerdem protokolliert:
ERROR: initiator has no right to access the target

Was mit den fehlenden Initiatoren in der ACL-Datei übereinstimmt.

Was funktioniert / Was nicht funktioniert
:white_check_mark: Funktioniert:

NAS startet normal
Speicherpools und LUNs sind gesund
SMB / NFS funktionieren einwandfrei
iSCSI-Dienst startet
Targets werden als „Bereit“ angezeigt
SCST lädt (create_and_open_dev devname /dev/isert_scst)

:cross_mark: Funktioniert NICHT:

Jeder ESXi iSCSI-Login
Explizites Initiator-Mapping
„Allow All“-Initiator
ACL-Regeneration via: iscsi_util --regen_conf iscsi_initlun_acl_conf
Firmware-Upgrade (einschließlich h6.0 Beta)

Nach aktuellem Stand deuten die Hinweise eher auf eine korrupte iSCSI-Kontroll-Ebene / IPC-Fehler als auf ein Konfigurationsproblem hin.

  1. Hat jemand den Fehler event_conn: write error Broken pipe im Zusammenhang mit iSCSI auf QuTS hero gesehen?

  2. Gibt es ein bekanntes Problem, bei dem SCST-Initiator-ACLs nicht dauerhaft gespeichert werden?

  3. Ist ein 3‑Sekunden-System-Reset die einzige unterstützte Methode, um diesen Zustand zu beheben?

  4. Hat jemand diesen Zustand ohne Zurücksetzen oder Neuinstallation des Betriebssystems behoben?

Hmm, ich betreibe iSCSI auf meinem NAS, das mit 3 x ESXi-Hosts über aktive/aktive 10GbE-Verbindungen zu meinen LUNs kommuniziert. Die Einrichtung scheint ziemlich unkompliziert zu sein und läuft nun schon seit ein paar Jahren problemlos. Ich habe bisher auch keinerlei Schreibfehler festgestellt.

Bei mir hat es lange Zeit problemlos funktioniert. Nach einem Firmware-Update im letzten Herbst verbinden sich die ISCSI-Targets jedoch nicht mehr. Die Übergangslösung vom QNAP-Support besteht darin, ein neues Target zu erstellen, die LUNs zu verschieben und dann das von den ESXi-Hosts verwendete Target zu ändern. Manchmal funktioniert das. Aber ich muss diesen Vorgang jedes Mal durchführen, wenn die ESXi-Hosts neu gestartet werden oder wenn ich den Labor-PC herunterfahre. Das ist wirklich lästig.

Wenn man etwas genauer hinschaut: Ja, ich benutze keine ACLs, ist meiner Meinung nach auch nicht nötig – das hier ist ein Homelab und so bleibt alles einfach. Wäre das ein echtes Büro mit richtigen Nutzern, dann vielleicht.

Dieses Problem sollte in einer späteren Version behoben worden sein. Bitte versuchen Sie, auf die neueste Version zu aktualisieren und prüfen Sie, ob das hilft. Vielen Dank!

Der Fix ist derzeit in der Beta-Version des Firmware-Updates enthalten. Ich habe schon 6 Monate gewartet, da kann ich auch noch warten, bis er aus der Beta kommt.