Mandi! Sérgio Basto via samba In chel di` si favelave...> As far as I can tell and in my experience the replications methods that > we find in wiki fail in be bi-directional. So to workaround we may > force just write POL(s) in just one DC and sync it to the other.AFAIK gpedit just write to the DC with FSMO role by default. https://wiki.samba.org/index.php/Rsync_based_SysVol_replication_workaround#Information_on_rsync-based_replication so, simply use as source the FSMO DC. -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.lanostrafamiglia.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)lanostrafamiglia.it t +39-0434-842711 f +39-0434-842797 Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA! http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000 (cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
I mentioned the DNS editing issue and I think that was giving us headaches as
well, but the actual problem was this:
/usr/local/samba/private/idmap.ldb was different enough on one of the DC's
so that after an rsync with acl's, uid's and everything,
sysvol on one server was not able to give access to the users because the
uid/gid's did not correspond to the right domain or builtin groups/users.
Copying /usr/local/samba/private/idmap.ldb over to the misbehaving server and
deleting its /usr/local/samba/var/locks/winbindd_cache.tdb seems to have fixed
the problem
On Thursday, 18 April 2019, 00:18:15 GMT-7, Marco Gaiarin via samba
<samba at lists.samba.org> wrote:
Mandi! Sérgio Basto via samba
In chel di` si favelave...
> As far as I can tell and in my experience the replications methods that
> we find in wiki fail in be bi-directional. So to workaround we may
> force just write POL(s) in just one DC and sync it to the other.
AFAIK gpedit just write to the DC with FSMO role by default.
https://wiki.samba.org/index.php/Rsync_based_SysVol_replication_workaround#Information_on_rsync-based_replication
so, simply use as source the FSMO DC.
--
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
Associazione ``La Nostra Famiglia''
http://www.lanostrafamiglia.it/
Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN)
marco.gaiarin(at)lanostrafamiglia.it t +39-0434-842711 f +39-0434-842797
Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
On Fri, 26 Apr 2019 18:22:54 +0000 (UTC) ray klassen via samba <samba at lists.samba.org> wrote:> > I mentioned the DNS editing issue and I think that was giving us > headaches as well, but the actual problem was > this: /usr/local/samba/private/idmap.ldb was different enough on one > of the DC's so that after an rsync with acl's, uid's and everything, > sysvol on one server was not able to give access to the users because > the uid/gid's did not correspond to the right domain or builtin > groups/users. Copying /usr/local/samba/private/idmap.ldb over to the > misbehaving server and deleting > its /usr/local/samba/var/locks/winbindd_cache.tdb seems to have fixed > the problem On Thursday, 18 April 2019, 00:18:15 GMT-7, Marco Gaiarin > via samba <samba at lists.samba.org> wrote: Mandi! Sérgio Basto via > samba In chel di` si favelave... > > > As far as I can tell and in my experience the replications methods > > that we find in wiki fail in be bi-directional. So to workaround we > > may force just write POL(s) in just one DC and sync it to the > > other. > > AFAIK gpedit just write to the DC with FSMO role by default. > > https://wiki.samba.org/index.php/Rsync_based_SysVol_replication_workaround#Information_on_rsync-based_replication > > so, simply use as source the FSMO DC. >Known problem, that well known, there is info on the wiki about it: https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory#Built-in_User_.26_Group_ID_Mappings Rowland