Hi Guys, I have run into a very interesting problem using GPO's on our DC's. As you may (or may not) know, we have migrated to a pure Samba4 (Git stable branch checkout) AD network. I can't be happier. *Kudos to the Samba team* We are running to DC's, DC1 and DC2, both full fledged DC's, both running CentOS 6.9, fully up to date. For the sysvol partition I decided to run a glusterfs between the DC's. I started out with a unison sync, but being the impatient person I am, I needed more real time. Now my problem is with the permissions in the sysvol folder structure. if I run a samba-tool ntacl sysvolreset on the one dc. The idmapping on the other dc goes all screwie on me. I copied the idmap.tdb.bak from dc1 to dc2 and restarted samba on dc2, but a getfacl on the sysvol directory gives me the wrong mappings. Is there a way to keep the idmappings in sync across the DC's, or maybe I can move to rid backend (is that even a possibility)? Sanitized smb.conf's at the following links DC1 https://www.jacklin.co.za/privatebin/?9afbe9b838970d12#qRr64hk3IUZTDF9ENZBgwVheYsygt9GylmYvT25y88Q DC2 https://www.jacklin.co.za/privatebin/?d584270a3af36cd1#zLXbprO30zR2WkC5NwGCXMANRaAtxoPvwceNNOmd+K0 Appreciate any advise Kind regards
On Wed, 22 Nov 2017 16:01:17 +0200 Ian Coetzee via samba <samba at lists.samba.org> wrote:> Hi Guys, > > I have run into a very interesting problem using GPO's on our DC's. > > As you may (or may not) know, we have migrated to a pure Samba4 (Git > stable branch checkout) AD network. I can't be happier. *Kudos to the > Samba team* > > We are running to DC's, DC1 and DC2, both full fledged DC's, both > running CentOS 6.9, fully up to date. > > For the sysvol partition I decided to run a glusterfs between the > DC's. I started out with a unison sync, but being the impatient > person I am, I needed more real time. > > Now my problem is with the permissions in the sysvol folder structure. >Sorry, but your problem is that you missed this: https://wiki.samba.org/index.php/Bidirectional_Rsync/osync_based_SysVol_replication_workaround#FAQ Where it quite clearly says this: Why can't I simply use a distributed filesystem like GlusterFS, Lustre, etc. for SysVol? A cluster file system with Samba requires CTDB to be able to do it safely. And CTDB and AD DC are incompatible. Rowland
On 22 November 2017 at 17:45, Rowland Penny <rpenny at samba.org> wrote:> On Wed, 22 Nov 2017 16:01:17 +0200 > Ian Coetzee via samba <samba at lists.samba.org> wrote: > > > Hi Guys, > > > > I have run into a very interesting problem using GPO's on our DC's. > > > > As you may (or may not) know, we have migrated to a pure Samba4 (Git > > stable branch checkout) AD network. I can't be happier. *Kudos to the > > Samba team* > > > > We are running to DC's, DC1 and DC2, both full fledged DC's, both > > running CentOS 6.9, fully up to date. > > > > For the sysvol partition I decided to run a glusterfs between the > > DC's. I started out with a unison sync, but being the impatient > > person I am, I needed more real time. > > > > Now my problem is with the permissions in the sysvol folder structure. > > > > Sorry, but your problem is that you missed this: > > https://wiki.samba.org/index.php/Bidirectional_Rsync/osync_ > based_SysVol_replication_workaround#FAQ > > Where it quite clearly says this: > > Why can't I simply use a distributed filesystem like GlusterFS, > Lustre, etc. for SysVol? > A cluster file system with Samba requires CTDB to be able to do it > safely. And CTDB and AD DC are incompatible. > > Rowland >Hi Rowland, Yes, you are right, I completely missed that part. I actually had the system set up using https://wiki.samba.org/index.php/Bidirectional_Rsync/Unison_based_SysVol_replication_workaround But then I decided to become creative with a glusterfs setup. I now have a Osync set up (much easier IMO), but the permissions are still not quite right, bringing me back to my idmap syncing question. Kind regards