ISCSI Targets do not connect - QuTS hero iSCSI failure: initiator ACLs not written to SCST (Broken pipe, ESXi cannot connect)

English Storage
1

I am currently experiencing a problem connecting to the ISCSI Target on my QNAP NAS TS-H973ax.

This has been ongoing since a firmware update back in Nov 2025.

QuTS hero iSCSI failure: initiator ACLs not written to SCST (Broken pipe, ESXi cannot connect)

I’m posting this in case others have hit the same issue and to see if anyone (or QNAP staff) can confirm whether this is a known QuTS hero bug.
Hardware / Software

NAS: QNAP TS‑h973AX
OS: QuTS hero (tested across multiple 5.x builds and h6.0.0.3397 beta)
iSCSI target stack: SCST
Initiators: VMware ESXi (running in VMware Workstation – lab environment)
Network: 2.5GbE, no firewall between initiator and NAS

Problem Summary
The iSCSI service starts and targets show as Ready in the GUI, but ESXi cannot connect to any iSCSI target.
After extensive troubleshooting, the root issue appears to be that initiator ACLs are never written into SCST, even when initiators are explicitly defined in the GUI. The ACL file always reverts to the default pseudo‑initiator.
As a result:

No iSCSI sessions are ever established
ESXi rescans complete with no errors but no devices appear
iSCSI is effectively unusable

Key Symptom
The ACL file always contains only the default policy, never real initiators:

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”
}
}

Even after:

Deleting all initiators
Recreating initiators with explicit ESXi IQNs
Regenerating ACLs
Restarting iSCSI
Upgrading firmware
Downgrading firmware

The ESXi IQNs never appear in the file.

Relevant Errors
During iSCSI restarts, the following appears repeatedly:
event_conn:965:ERROR: write error Broken pipe

This seems to indicate that the QNAP iSCSI management service cannot communicate with the SCST control socket, so ACL updates never persist.
Earlier in troubleshooting, SCST also logged:
ERROR: initiator has no right to access the target

Which aligns with the missing initiators in the ACL file.

What Works / What Doesn’t
:white_check_mark: Works:

NAS boots normally
Storage pools and LUNs are healthy
SMB / NFS work fine
iSCSI service starts
Targets show Ready
SCST loads (create_and_open_dev devname /dev/isert_scst)

:cross_mark: Does NOT work:

Any ESXi iSCSI login
Explicit initiator mapping
“Allow All” initiator
ACL regeneration via: iscsi_util --regen_conf iscsi_initlun_acl_conf
Firmware upgrade (including h6.0 beta)

At this point, the evidence suggests a corrupted iSCSI control plane / IPC failure rather than a configuration problem.

2

  1. Has anyone seen event_conn: write error Broken pipe in relation to iSCSI on QuTS hero?

  2. Is there a known issue where SCST initiator ACLs fail to persist?

  3. Is a 3‑second system reset the only supported way to clear this state?

  4. Has anyone recovered from this without resetting or reimaging the OS?

3

Hmm, running iSCSI on my NAS talking to 3 x ESXi hosts with active/active 10GbE links to my LUNs, the setup seems to be fairly straightforward and has been working for a few years now. I have not seen any write errors at all, either.

4

Mine worked without issue for a long time. After a firmware update last fall, the ISCSI Targets will not connect. The workaround from QNAP support is to create a new Target and move the LUNs over then change the target being used by the ESXi hosts. Sometimes this works. But I have to deal with that process any time the ESXi hosts are rebooted or if I power down the lab PC. It’s a real pain.

5

Looking a bit closer, yeah, I don’t use ACLs, no need to, IMO this is a homelab and it keeps things simple, but if this were an actual office with real users, then maybe.

image
image1258×896 73.6 KB

6

This issue should have been resolved in a later version. Please try updating to the latest version and see if it helps. Thanks!