Enterprise Storage OS master_be7d7b1: SCST 3.9.0, clients cannot locate the resource

[Mr Dandy]

Hello, I'm trying to create SCTP configuration for block device:

1) Device -> Add device -> vdisk_fileio -> Block device -> vdb ('dsk1' ask name)
2) Targets -> Add iSCSI Target -> 'iqn.172.16.0.3:target0'
3) Hosts -> Add Group -> 'iqn.172.16.0.3:target0" -> "mygroup1'
4) Device -> Map to Host Group -> 'dsk1' -> 'iqn.172.16.0.3:target0' -> 'mygroup1' -> Lun 0
5) Targets -> Enable/Disable Target -> 'iqn.172.16.0.3:target0' -> Enable

Result, /etc/scst.conf:
```
# Automatically generated by SCST Configurator v3.9.0.


HANDLER vdisk_fileio {
       DEVICE dsk1 {
               filename /dev/vdb
       }
}

TARGET_DRIVER copy_manager {
       TARGET copy_manager_tgt {
               LUN 1 dsk1
       }
}

TARGET_DRIVER iscsi {
       enabled 1

       TARGET iqn.172.16.0.3:target0 {
               enabled 1
               rel_tgt_id 1

               GROUP mygroup1 {
                       LUN 0 dsk1
               }
       }
}
```

```
/etc/rc.d/rc.scst stop && /etc/rc.d/rc.scst start
Stopping SCST userland daemons...
Unloading SCST kernel modules...
Loading SCST kernel modules...
Starting SCST userland daemons...
Applying SCST configuration...

Collecting current configuration: done.

-> Checking configuration file '/etc/scst.conf' for errors.
       -> Done, 0 warnings found.

-> Applying configuration.
       -> Opening device 'dsk1' using handler 'vdisk_fileio': done.
       -> Adding device 'dsk1' at LUN 1 to driver/target 'copy_manager/copy_manager_tgt': done.
       -> Creating target 'iqn.172.16.0.3:target0' for driver 'iscsi': done.
       -> Setting target attribute 'rel_tgt_id' to value '1' for driver/target 'iscsi/iqn.172.16.0.3
:target0': done.
       -> Adding new group 'mygroup1' to driver/target 'iscsi/iqn.172.16.0.3:target0': done.
       -> Adding device 'dsk1' at LUN 0 to driver/target/group 'iscsi/iqn.172.16.0.3:target0/mygroup
1': done.
       -> Enabling driver/target 'iscsi/iqn.172.16.0.3:target0': done.
       -> Enabling driver 'iscsi': done.
       -> Done, 8 change(s) made.
       -> Driver/target 'copy_manager/copy_manager_tgt' has no 'host' attribute, ignoring.
       -> Driver/target 'iscsi/iqn.172.16.0.3:target0' has no 'host' attribute, ignoring.

All done.
```


However, clients do not find anything when discovery and cannot connect the resource.

However, if I manually delete the group in the /etc/scst.conf configuration file, everything works:
```
# Automatically generated by SCST Configurator v3.9.0.


HANDLER vdisk_fileio {
       DEVICE dsk1 {
               filename /dev/vdb
       }
}

TARGET_DRIVER copy_manager {
       TARGET copy_manager_tgt {
               LUN 1 dsk1
       }
}

TARGET_DRIVER iscsi {
       enabled 1

       TARGET iqn.172.16.0.3:target0 {
               enabled 1
               rel_tgt_id 1

#               GROUP mygroup1 {
                       LUN 0 dsk1
#               }
       }
}
```
+ `/etc/rc.d/rc.scst stop && /etc/rc.d/rc.scst start`

What did I miss? Any advice is welcome. Thanks!

[Marc Smith]

If you're using security groups, you must add initiator names to the
groups to give them access.

--Marc


>
> --
> You received this message because you are subscribed to the Google Groups "esos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to esos-users+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/esos-users/a315bd21-f44d-48a1-b773-ca93892862dbn%40googlegroups.com.

[Subbsd]

On Tue, Feb 18, 2025 at 5:29 PM Marc Smith <msmi...@gmail.com> wrote:
> If you're using security groups, you must add initiator names to the
> groups to give them access.
>
> --Marc

Thanks, Mark! With the security group and the initiator name everything works.
Do I understand correctly that through TUI we cannot create a
fully/widely open resource (since the configuration is always
generated with a 'group'), but it is OK if we manually delete the
"group" directly in the configuration file?
For testing purposes, I plan to provide access to a large number of
devices whose names I do not know in advance.

[Marc Smith]

On Tue, Feb 25, 2025 at 12:45 PM Subbsd <sub...@gmail.com> wrote:
>
> On Tue, Feb 18, 2025 at 5:29 PM Marc Smith <msmi...@gmail.com> wrote:
> > If you're using security groups, you must add initiator names to the
> > groups to give them access.
> >
> > --Marc
>
> Thanks, Mark! With the security group and the initiator name everything works.
> Do I understand correctly that through TUI we cannot create a
> fully/widely open resource (since the configuration is always
> generated with a 'group'), but it is OK if we manually delete the
> "group" directly in the configuration file?

Yes, that works; or you can simply use a wild card in the initiator
name to match a pattern, or all (*).

--Marc

> For testing purposes, I plan to provide access to a large number of
> devices whose names I do not know in advance.
>

> --
> You received this message because you are subscribed to the Google Groups "esos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to esos-users+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/esos-users/CAFt_eMrS22szYgC9e8-E20587M3it7OhrRvhW%2BBeJbjLxzSXfA%40mail.gmail.com.