I have a fresh install of TrueNAS Scale to which I have added several iSCSI targets. The targets are all on their own LUN and they are discoverable and accessible from both Windows and Linux. My intention is to use each target for storing backups of individual PCs. (File History in the case of Windows.)
I am trying to harden the shares by adding CHAP authentication to each. I would like to use unique users and secrets for each target. My problem occurs when I try to add an Authorized Access Group. When a group is added, all of the targets become un-discoverable even though I have not changed any of the target’s settings to include CHAP authentication.
I am new to iSCSI, so it is quite possible that I just don’t understand how it is supposed to work. Any advice or guidance, to include leading questions, would be greatly appreciated.
Edit:
Here is what I get when I try to discover the targets before and after adding an Access Group:
russ@Russ-Ubuntu20:~$ echo Before adding access group:
Before adding access group:
russ@Russ-Ubuntu20:~$ sudo iscsiadm --mode discovery --type sendtargets --portal 192.168.1.99
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:kentwin
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:recwin
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:russlin
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:russwin
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:sageback
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:sarahwin
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:shipwin
192.168.1.99:3260,1 iqn.2005-10.org.freenas.ctl:shopwin
russ@Russ-Ubuntu20:~$
russ@Russ-Ubuntu20:~$
russ@Russ-Ubuntu20:~$ echo After adding access group:
After adding access group:
russ@Russ-Ubuntu20:~$ sudo iscsiadm --mode discovery --type sendtargets --portal 192.168.1.99
iscsiadm: Login failed to authenticate with target
iscsiadm: discovery login to 192.168.1.99 rejected: initiator failed authorization
iscsiadm: Could not perform SendTargets discovery: iSCSI login failed due to authorization failure
russ@Russ-Ubuntu20:~$
Interesting, I’m able to reproduce this. Let me see if this is documented in the target driver somewhere that creating auth groups is expected to require them for discovery against all targets.
So this is odd. I saw a momentary disruption in discovery when creating the very first access group - but it righted itself after a minute (probably less, I didn’t run a clock on it) and now I can remove and re-add them freely without impacting discovery or connectivity from anonymous clients.
Are you able to try an upgrade to the latest 25.10.2.1 release, and see if the issue persists there?
After upgrading to 25.10.1.2, I see no change in behavior. My system does not “right itself”. The only way I can restore discovery is to delete the access group.
I have not submitted a bug report before, so I may need a little hand holding. I’ll try to do it now.
I mean 24.10.2 (“Electric Eel”). I started on this hardware with 25.04.2.6 (“Fangtooth”) and had the problem described above. I then upgraded to 25.10.2 (“Goldeye”) and saw no change in behavior. I then did a fresh install of 24.10.2 (“Electric Eel”) and was able to implement iSCSI shares as expected. I hope this helps.
That does help, thank you - but 24.10 isn’t getting any further updates and staying “behind the times” on features and functionality isn’t exactly what we’d hope for here. I’ll follow up with Engineering to see if there’s any change.
