> 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

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

On Sat, Oct 13, 2012 at 8:58 AM, Andrew Bartlett <abart...@samba.org> wrote:
> 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

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

> Thanks a lot

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.

On Tue, 2012-10-16 at 13:17 +1100, Andrew Bartlett wrote:
> 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?)

On Tue, 2012-10-16 at 18:09 +1100, Andrew Bartlett wrote:
> On Tue, 2012-10-16 at 13:17 +1100, Andrew Bartlett wrote:
> > 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?)

> 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.

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 ;*

> On Tue, 2012-10-16 at 13:17 +1100, Andrew Bartlett wrote:
> > 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?)

> 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.

> Andrew Bartlett

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