zfs discuss - Dec 2007 - Delegating iscsishare zfs permissions (iscsitgtd privileges)

I have created a user ''block'' which has the following ZFS
permissions on tank/iscsi_luns.

-bash-3.2# zfs allow tank/iscsi_luns
-------------------------------------------------------------
Local+Descendent permissions on (tank/iscsi_luns)
        user block
clone,create,destroy,mount,mountpoint,promote,rename,reservation,rollback,shareiscsi,snapshot,volsize
-------------------------------------------------------------

I would like ''block'' to give the ability to create volumes
under iscsi_luns, so user block can operate without superuser right. But upon
create:

/usr/sbin/zfs create -V 1m tank/iscsi_luns/test
cannot share ''tank/iscsi_luns/test'': iscsitgtd failed request
to share
filesystem successfully created, but not shared

An error is generated, with the following dmesg:

Dec  2 15:21:26 troeteldier iscsitgtd[9870]: [ID 998699 user.error]
transaction_start start: insufficient privileges for action

Should my user block be placed in a special group in order to share via iSCSI?
Why isn''t this working out of the box?
 
 
This message posted from opensolaris.org

Stefan de Konink wrote:
> I have created a user ''block'' which has the following ZFS
permissions on tank/iscsi_luns.
> 
> -bash-3.2# zfs allow tank/iscsi_luns
> -------------------------------------------------------------
> Local+Descendent permissions on (tank/iscsi_luns)
>         user block
clone,create,destroy,mount,mountpoint,promote,rename,reservation,rollback,shareiscsi,snapshot,volsize
> -------------------------------------------------------------
> 
> I would like ''block'' to give the ability to create
volumes under iscsi_luns, so user block can operate without superuser right. But
upon create:
> 
> /usr/sbin/zfs create -V 1m tank/iscsi_luns/test
> cannot share ''tank/iscsi_luns/test'': iscsitgtd failed
request to share
> filesystem successfully created, but not shared
> 
> An error is generated, with the following dmesg:
> 
> Dec  2 15:21:26 troeteldier iscsitgtd[9870]: [ID 998699 user.error]
transaction_start start: insufficient privileges for action
> 
> Should my user block be placed in a special group in order to share via
iSCSI? Why isn''t this working out of the box?
>  
You need to give out ''share'' permission as well.  The
shareiscsi
permission only allows you to manipulate the property, whereas
''share''
lets you share the volume.

   -Mark

Stefan de Konink wrote:
> Hi Mark,
> 
> Local+Descendent permissions on (tank/iscsi_luns)
>         user block
>
clone,create,destroy,mount,mountpoint,promote,rename,reservation,rollback,share,shareiscsi,snapshot,volsize
> 
> (added share)
> 
> The strange thing is that the command seems to fail:
> 
What opensolaris build are you using?
> -bash-3.2$ ./create.sh skinkie test 1m
> cannot share ''tank/iscsi_luns/skinkie_test'': iscsitgtd
failed request to
> share
> filesystem successfully created, but not shared
> iqn.1986-03.com.sun:02:51e9b650-6eef-c504-b2ae-8914bafce5e6
> 
I''ve seen this sort of thing before.  There is a bug in iscitgtd that 
use to cause this sort of error on the first request to share.  I''m not
sure if that bug has been fixed yet.
> But the luns were made :{
> 
> Target: tank/iscsi_luns/test
>     iSCSI Name:
> iqn.1986-03.com.sun:02:319bb303-3b1a-ebde-eb05-f2b3d9adbe86
>     Connections: 0
> Target: tank/iscsi_luns/skinkie_test
>     iSCSI Name:
> iqn.1986-03.com.sun:02:51e9b650-6eef-c504-b2ae-8914bafce5e6
>     Connections: 0
> 
> 
> What I also see is that the LUN is not removed on the destroy command.
> If the destroy command is executed as root it is removed as target.
> 
as long as you have destroy it should remove the target.
> I implemented sudo now as wrapper around my script to get it to work, but
> some follow up on the errors is welcome.
> 
I''m seeing some other issues with delegation+iscisi with the latest 
Nevada bits.  I will need to investigate them and will likely raise some 
bugs once I figure out whats going on.

   -Mark

>> I''m seeing some other issues with delegation+iscisi with the
latest
>> Nevada bits.  I will need to investigate them and will likely raise
some
>> bugs once I figure out whats going on.
> 
> Thanks. For now my sudo wrapper works, but I would be very happy if this
> can be sorted out without any hacks.
> 
> 
Stefan,

Looks like delegation+iscsi works in snv_74, but not snv_75+.

I''ve opened the following bug to address this.

6636599 Integration of PSARC/2007/414 broke zfs delegated admin support
         of shareiscsi

The integration PSARC/2007/414 went into build 75.

   -Mark