similar to: Log of DC replication error

I have 2 AD DC and apparently there is something wrong with the replication. samba-tool drs showrepl returns kinda different information for the two: ---8<----------- First DC: Default-First-Site-Name\SAMBA DSA Options: 0x00000001 DSA object GUID: b19509be-c3ee-4a58-9fc9-afd61759a23f DSA invocationId: 4f30d79d-2e9c-4235-88a1-c258b8622d23 ==== INBOUND NEIGHBORS ====

It did happen again and this time I was a little less panicked and took some time to figure out what happened. On my primary DC (SAMBA) I did not notice anything extraordinary. However, my secondary (VERDANDI) reported issues: root at verdandi:~# samba-tool drs showrepl Default-First-Site-Name\VERDANDI DSA Options: 0x00000001 DSA object GUID: a03bbb51-1dca-44ae-a4d9-7aa8cb4a1ace DSA

Hi Marc, >> The cause is that the password change didn' reach both AD DCs, but only >> one. The other one still had the old value as could be seen by >> samba-tool ldapcmp. Restarting the DCs and waiting for a couple of >> seconds brings them back to sync and Windows logons work as they used to. >> Any idea, what I should do next time to obtain valuable output

Hi, I'm resending this to the list since I cannot see it on the archive, for some reason... I recently upgraded two (running stable) systems from Debian Wheezy to Jessie. Samba version has not changed since on Wheezy I was using the one from wheezy-backports (v4.1.17), same as on jessie. These are 2 basic DCs without any additional config. Since the upgrade, every day at either at 10 PM or 8

After deletion and recreation of the reverse zone Bind9 started again. Thanks to Rowland for the hint. However, bind complains that virtually all zones are duplicate and thus at least one issue is ignored. Since it's samba_dlz complaining there's either something wrong in the AD or in the DLZ module. The Bind does not have any other zones than the DLZ. I have trouble connecting

On 29/12/14 09:40, Lars Hanke wrote: > And some more information about this strange effect apparently no-one > has seen before. > > I now added the missing zone: > > samba-tool dns zonecreate verdandi 10.16.172.in-addr.arpa -U > Administrator > > and it claims that the zone is okay, but the next one is missing: > > Dec 29 10:31:12 verdandi named[2601]: Loading

And some more information about this strange effect apparently no-one has seen before. I now added the missing zone: samba-tool dns zonecreate verdandi 10.16.172.in-addr.arpa -U Administrator and it claims that the zone is okay, but the next one is missing: Dec 29 10:31:12 verdandi named[2601]: Loading 'ad.microsult.de' using driver dlopen Dec 29 10:31:12 verdandi named[2601]:

You did change : the DLZ option from 9.8 to 9.9 ? check your bind options. this .. dlz "AD DNS Zone" { # For BIND 9.8.x # database "dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9.so"; # For BIND 9.9.x database "dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so"; # For BIND 9.10.x # database "dlopen

Just to clarify some things ... the Bind9 and Samba4 are both current Debian Jessie on amd64. So the applicable changelog would be http://metadata.ftp-master.debian.org/changelogs//main/b/bind9/testing_changelog Using 1:9.9.5.dfsg-6 the system worked nicely. Fixing a CVE pertaining to recursion does not easily link to DLZ issues. The system definitely has DLZ included. Otherwise it could not

I dug somewhat deeper into what is going on below and it seems even stranger. The reverse zone without SOA or NS does not even exist: root at verdandi:~# samba-tool dns query localhost 10.16.172.in-addr.arpa @ ALL -U Administrator Password for [AD\Administrator]: ERROR(runtime): uncaught exception - (9714, 'WERR_DNS_ERROR_NAME_DOES_NOT_EXIST') File

I just upgraded bind9 on my backup DC to 9.9.5-7-Debian and restarting the service failed: Dec 22 12:25:55 verdandi named[18534]: starting BIND 9.9.5-7-Debian -u bind -4 Dec 22 12:25:55 verdandi named[18534]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var'

Last month I struggled with a severe DLZ issue and today I could solve it. Credits for the important idea go to Peter Serbe, thanks! I checked the DNS contents using RSAT. There was nothing wrong with SOA nor NS entries, but the reverse zones were actually forward zones with proper names in the in-addr.arpa. domain. I built proper reverse zones and deleted the forward-reverse zones and Bind

I'd check for differences in the ldap trees with samba-tool ldapcmp first If such are found try an manual full sync replication to fix the difference. I had an similar issue a while back and an deleted object on one dc caused such sigterm's. Had to get that deleted object out of the way afterwards the dc's where stable again. Am 30.03.2016 um 14:35 schrieb Prunk Dump: > Hello

On 30/03/16 13:35, Prunk Dump wrote: > Hello Samba team ! > > On my network I have three Samba-4.1.17 domain controllers (Debian Jessie) : > -> One PDC : pdc01 > -> Two "slave" DC : sdc02, sdc03 > > I don't know why, but sometimes Samba receive the SIGTERM signal and > restart even if I remove it from the logrotate configuration. On >

>> >> Hello Samba team ! >> >> On my network I have three Samba-4.1.17 domain controllers (Debian Jessie) >> : >> -> One PDC : pdc01 >> -> Two "slave" DC : sdc02, sdc03 >> >> I don't know why, but sometimes Samba receive the SIGTERM signal and >> restart even if I remove it from the logrotate configuration. On >>

Hello Samba team ! On my network I have three Samba-4.1.17 domain controllers (Debian Jessie) : -> One PDC : pdc01 -> Two "slave" DC : sdc02, sdc03 I don't know why, but sometimes Samba receive the SIGTERM signal and restart even if I remove it from the logrotate configuration. On "pdc01" I see : ---------- pdc01 (log.samba) ---------- SIGTERM: killing children

2016-04-01 23:36 GMT+02:00 Rowland penny <rpenny at samba.org>: > On 30/03/16 13:35, Prunk Dump wrote: >> >> Hello Samba team ! >> >> On my network I have three Samba-4.1.17 domain controllers (Debian Jessie) >> : >> -> One PDC : pdc01 >> -> Two "slave" DC : sdc02, sdc03 >> >> I don't know why, but sometimes Samba

Dear Roland, and here we have one reasons / prove regarding Debian and current Samba BIND DLZ issues : http://metadata.ftp-master.debian.org/changelogs//main/b/bind9/bind9_9.8.4.dfsg.P1-6+nmu2+deb7u3_changelog MSG >> " * disable dlz until we get a patch to make it build again" Well Debian Maintainers seems seeking missing the dlz patches that RHEL & SLES maintainers created

It's probably difting slightly off the topic, but I know that there are some people listening here, who have a decent expertise. I'm trying to setup a file server (nfs4 at ad.domain) and mount from a client (hunin at ad.domain) using the user database and especially Kerberos provided by my AD (samba at ad.domain). It already works nicely, if I forget about krb5, i.e. idmapd is

Recently I suddenly lose all permissions both for SMB and NFS4 on my Synology NAS.And similarly after poking some time in muddy waters, it suddenly works again. The NAS runs Samba 3.6.9. What I found, when the permissions were gone: 1. id user still working, didn't work last time so I assume a caching issue here 2. wbinfo -u same as above. This time still worked, last time only reported