[Samba] can not change mandatory owner to administrators

Mohammad Ebrahim Abravi

unread,

Oct 8, 2012, 7:30:02 AM10/8/12

to

Hello

upgrading from samba 4alpha17 to samba4beta8.

Problem :
*can`t change mandatory profile owner to Administrators and see This error:
this security ID may not be assigned as the owner of this object
administrators *

now my mandatory profile not work !

thanks a lot
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Mohammad Ebrahim Abravi

unread,

Oct 13, 2012, 12:50:02 AM10/13/12

to

Now Upgrade to samba 4.0.0rc2 But Again the error is observed !!

*this security ID may not be assigned as the owner of this object
administrators *

On Mon, Oct 8, 2012 at 2:49 PM, Mohammad Ebrahim Abravi
<lamp...@gmail.com>wrote:

Andrew Bartlett

unread,

Oct 13, 2012, 1:30:02 AM10/13/12

to

On Sat, 2012-10-13 at 08:19 +0330, Mohammad Ebrahim Abravi wrote:
> Now Upgrade to samba 4.0.0rc2 But Again the error is observed !!
>
> *this security ID may not be assigned as the owner of this object
> administrators *
>
> On Mon, Oct 8, 2012 at 2:49 PM, Mohammad Ebrahim Abravi
> <lamp...@gmail.com>wrote:
>
> > Hello
> >
> > upgrading from samba 4alpha17 to samba4beta8.
> >
> > Problem :
> > *can`t change mandatory profile owner to Administrators and see This
> > error:
> > this security ID may not be assigned as the owner of this object
> > administrators *
> >
> > now my mandatory profile not work !
> >
> > thanks a lot
> >

If you return to using the ntvfs file server, does it work again? (This
isn't a very long term solution, but it certainly could help us isolate
the issue).

https://wiki.samba.org/index.php/Samba4/s3fs#Using_it

server services = +smb -s3fs
dcerpc endpoint servers = +winreg +srvsvc

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

Mohammad Ebrahim Abravi

unread,

Oct 13, 2012, 2:30:01 AM10/13/12

to

Solved

Thanks a lot

Andrew Bartlett

unread,

Oct 13, 2012, 4:40:02 AM10/13/12

to

On Sat, 2012-10-13 at 09:58 +0330, Mohammad Ebrahim Abravi wrote:
> Solved
>
> Thanks a lot

Thanks.

The root of the issue is this automatically generated entry in your
idmap.ldb:

# record 12
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_GID
xidNumber: 10
distinguishedName: CN=S-1-5-32-544

What we need to do in your case is to remove that record, so it becomes
regenerated as an IDMAP_BOTH. We also need to remove the generation of
that record from provision.

The issue is that as a GID, you of course can't own a file. The ntvfs
file server papered over this issue (didn't deal with file ownership at
a unix level), but the smbd file server needs to correctly set posix
permissions.

I hope this clarifies things. If you can please file a bug, I'll try
not to forget this.

Thanks,

Andrew Bartlett

unread,

Oct 15, 2012, 10:20:01 PM10/15/12

to

On Sat, 2012-10-13 at 19:30 +1100, Andrew Bartlett wrote:
> On Sat, 2012-10-13 at 09:58 +0330, Mohammad Ebrahim Abravi wrote:
> > Solved
> >
> > Thanks a lot
>
> Thanks.
>
> The root of the issue is this automatically generated entry in your
> idmap.ldb:
>
> # record 12
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_GID
> xidNumber: 10
> distinguishedName: CN=S-1-5-32-544
>
>
> What we need to do in your case is to remove that record, so it becomes
> regenerated as an IDMAP_BOTH. We also need to remove the generation of
> that record from provision.
>
> The issue is that as a GID, you of course can't own a file. The ntvfs
> file server papered over this issue (didn't deal with file ownership at
> a unix level), but the smbd file server needs to correctly set posix
> permissions.
>
> I hope this clarifies things. If you can please file a bug, I'll try
> not to forget this.

The attached patch should prevent this for a new provision. Are you
able to test if this fixes things for you (on a new test domain?)

0001-provision-No-longer-use-the-wheel-group-in-new-AD-Do.patch

Andrew Bartlett

unread,

Oct 16, 2012, 3:10:01 AM10/16/12

to

This updated version uses the primary group of root (or the --root user)
rather than hoping that there will be a group by the same name.

0001-provision-No-longer-use-the-wheel-group-in-new-AD-Do.patch

Andrew Bartlett

unread,

Oct 17, 2012, 7:40:02 AM10/17/12

to

Fixing this and not breaking tests that subtly depend on idmap
configuration is proving tricky, but I'll get this sorted soon.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

Andrew Bartlett

unread,

Oct 31, 2012, 5:50:02 AM10/31/12

to

On Wed, 2012-10-31 at 13:10 +0330, Mohammad Ebrahim Abravi wrote:
> Hello
>
> Remove This Record and problem solved without add "server services = +smb
> -s3fs " and " dcerpc endpoint servers = +winreg +srvsvc" to smb.conf
>
> idmap.ldb:

>
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_GID
> xidNumber: 10

> distinguishedName: CN=S-1-5-32-544**
>
> *Note: BUG : Upgrade To samba rc4 and run samba-tool dbcheck but not fix
> this record ;*

Sadly we can't 'just fix' this, because it changes which unix gid files
are owned by. We can however suggest it to administrators in release
notes, I'll try and get that set when we fix the release branch.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

Mohammad Ebrahim Abravi

unread,

Oct 31, 2012, 5:50:03 AM10/31/12

to

Hello

Remove This Record and problem solved without add "server services = +smb
-s3fs " and " dcerpc endpoint servers = +winreg +srvsvc" to smb.conf

idmap.ldb:

dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_GID
xidNumber: 10

distinguishedName: CN=S-1-5-32-544**

*Note: BUG : Upgrade To samba rc4 and run samba-tool dbcheck but not fix
this record ;*