similar to: Samba is now on GitHub!

On Mon, 2020-08-17 at 12:05 +0530, Anoop C S via samba wrote: > Hi all, > > This is to announce the availability of Samba(and CTDB) rpms from > Storage SIG[1] on CentOS 7 and 8. Visit Samba's CentOS wiki page[2] > for > more details on installation steps. > > [1] https://wiki.centos.org/SpecialInterestGroup/Storage > [2]

Hello Andrew, 1. What is the explanation for the fact that when the log level is set to 5 or 7, the NT_STATUS_IO_TIMEOUT error does not appear, but when it is at the default log level, it does? Another point I've noticed before is that when I run the command "samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix --yes" (*Checked 15337 objects (0 errors)*), and in another

1.5 seconds is pretty long, I would look into what those queries are. I would also look into repeated queries, sometimes these things are clients stuck in a loop where they don't complete because they expect some termination condition. Andrew Bartlett On Tue, 2024-04-02 at 09:25 -0300, Elias Pereira via samba wrote: > The saga continues... > I've spent a whole day with log level 5

On Thu, 2024-04-11 at 14:21 -0300, Elias Pereira wrote: > Hello?Andrew, > > 1. What is the explanation for the fact that when the log level is > set to 5 or 7, the NT_STATUS_IO_TIMEOUT error does not appear, but > when it is at the default log level, it does? I don't have an explanation for this, sorry. ?Have you looked into the 1.5 second queries, what is sending them and

hi Andrew, thanks for the help!!! It seems to me the LDAP process being busy would be the root cause here. > Working out what is going on here shouldn't is a detective task - I always > start with a wireshark trace. The client making all the noise/traffic will > be the one causing the trouble. In the wireshark analysis, should I filter only by the ldap protocol or leave

That did the trick for manual replication via samba-tool drs replicate dc02 dc01 dc=ds,dc=example,dc=com --sync-all --local -d 9 However, if I run samba-tool drs showrepl it shows me a result 1326 (WERR_LOGON_FAILURE) and also samba-tool drs replicate dc02 dc01 dc=ds,dc=example,dc=com --full-sync fails with the same error. How can I fix this? On 3. March 2020 at 04:23:02, Andrew

OK, found this post from Louis and this fixed it for me. https://lists.samba.org/archive/samba/2019-April/222278.html @Andrew: thanks so much for your time, effort and support the last days! Alexander On 3. March 2020 at 10:01:59, Alexander Harm (alexander.harm at apfel-q.de) wrote: That did the trick for manual replication via samba-tool drs replicate dc02 dc01 dc=ds,dc=example,dc=com

Thanks for the explanation. I have a few more sites which I will test today and feedback if a manual sync of the DNS partition solves the problem as well. Alexander On 3. March 2020 at 18:54:02, Andrew Bartlett via samba (samba at lists.samba.org) wrote: So, the reason this happens is if in the long time replication to this DC has been broken the local idea of the DNS layout for the other

Exactly! On 3. March 2020 at 11:07:02, L.P.H. van Belle via samba (samba at lists.samba.org) wrote: Just to confirm this. Im guessing you use this part : > For the DsREplicatSync error, i would suggest these steps first. > DC2, change the resolv.conf, set DC1 first, then DC2, reboot. > Wait 5 min, now check replication again, if its ok, now you can change > the

Hello Andrew, What's the explanation for when the log level is set to 5, the error NT_STATUS_IO_TIMEOUT doesn't appear, but when it's at the default log level, it does? On Mon, Mar 18, 2024 at 10:33?AM Elias Pereira <empbilly at gmail.com> wrote: > hi Andrew, thanks for the help!!! > > It seems to me the LDAP process being busy would be the root cause here. >>

On Fri, 2020-10-30 at 14:10 -0500, Rob Townley wrote: > So is that a bind type not mentioned in the chart he referenced for > ldp.exe? Kerberos authentication is mentioned as: > Understanding bind options for LDAP authentication > There are several authentication methods available in ldp that allow > a client to bind to an LDAP server. The best method depends on > several

Thanks for getting back to me. It seems to me the LDAP process being busy would be the root cause here. Working out what is going on here shouldn't is a detective task - I always start with a wireshark trace. The client making all the noise/traffic will be the one causing the trouble. If it isn't clear from that, then look into the DB audit logging for perhaps busy writes

I understand but do you think the work will be done to make it compatible again ? If not, there should be a statement in the changelog about this broken compatibility. Christophe Borivant ----- Mail original ----- De: "Andrew Bartlett" <abartlet at samba.org> À: "Christophe BORIVANT" <cborivant at devinlec.com>, "samba" <samba at lists.samba.org>

Thank you both for digging into this. As you have seen this is a tricky area for Samba, being as it involves external services, additional (and it seems changing) essentially third-party software (not just base Windows) and has consistently fallen into a gap of 'almost working' for a number of years. The fact that there is a viable workaround (pass-though authentication) also seems to be

The saga continues... I've spent a whole day with log level 5 and 7 and no error. All I have to do is return the log to the default and the error reappears. I monitored the "LDAP Query: Duration", but I didn't notice any crashes in the queries. I don't know if it's a long time, but some queries took 1.5s. Is there anything else I can do? On Mon, Mar 25, 2024 at

Hi there, I was wondering, if there are any more ideas regarding this matter. Have a nice weekend, Alexander On 12. February 2020 at 07:07:02, Andrew Bartlett via samba (samba at lists.samba.org) wrote: I've been busy with other matters, including a serious issue with SCOPE_ONELEVEL searches ( https://gitlab.com/samba-team/samba/-/merge_requests/1125). If this is urgent or

Hi Andrew, no offence. I was just wondering if I could get around this issue if I nuke my Samba DCs and start fresh? Regards, Alexander On 12. February 2020 at 07:07:02, Andrew Bartlett via samba (samba at lists.samba.org) wrote: I've been busy with other matters, including a serious issue with SCOPE_ONELEVEL searches ( https://gitlab.com/samba-team/samba/-/merge_requests/1125).

Hi Andrew, you can use my name if you want (Alexander Harm). I will try and build with your patch. Alexander On 8. February 2020 at 00:30:02, Andrew Bartlett (abartlet at samba.org) wrote: Thanks. At this stage is looks like a bug in the repl_meta_data module. Try the attached patch. Can I name you in the bug and is there any affiliation (eg employer) you would like named?

Hi there, I would like to continue on this one. I applied the patch but am wondering which package it influences. If it is just the two mentioned than it did not fix the error. Regards, Alexander On 8. February 2020 at 09:46:11, Alexander Harm (alexander.harm at apfel-q.de) wrote: Hi Andrew, I applied your patch to the Debian packages of Louis. Do you happen to know in which package it

Hi Andrew, thanks for your feedback. What are my options now? Nuke the whole thing? Alexander On 24. February 2020 at 02:08:02, Andrew Bartlett via samba (samba at lists.samba.org) wrote: G'Day Alexander, This is looking trickier than I had hoped. I don't think the patch I included is the right approach, and I can't reproduce what I thought was the issue on master.