similar to: Failed samba_kcc - NT_STATUS_IO_TIMEOUT

hi, *EDIT*: Every 2 hours kcc_periodic.c is executed The error occurs on all 4 of my DCs: [2024/01/19 14:02:05.917120, 0] source4/dsdb/kcc/kcc_periodic.c:790(samba_kcc_done) source4/dsdb/kcc/kcc_periodic.c:790: Failed samba_kcc - NT_STATUS_IO_TIMEOUT Today I enabled logging at level 5 and monitored DC1. There was no error, on the contrary, kcc_periodic.c ran correctly and the message was Ok.

hi, Every 2 hours run kcc_periodic.c The error occurs on all 4 of my DCs: [2024/01/19 14:02:05.917120, 0] source4/dsdb/kcc/kcc_periodic.c:790(samba_kcc_done) source4/dsdb/kcc/kcc_periodic.c:790: Failed samba_kcc - NT_STATUS_IO_TIMEOUT Today I enabled logging at level 5 and monitored DC1. There was no error, on the contrary, kcc_periodic.c ran correctly and the message was Ok. [2024/01/19

Our domain controllers have run samba 4.4.3 since it was released. We didn't upgrade because it was so stable :) I recently decided that release was too old and upgraded to 4.8.2 (then current). Our domain controllers were crashing on 4.8.2 so I upgraded to 4.8.3 as soon as it was released but this has not resolved the issue. When the issue occurs the DC becomes unresponsive and needs to be

I could really use some support with this. I understand it's always possible to just restore from a backup but the more interesting question is if something can be done with the data at hand. Basically, I'm trying to understand how it's possible that a dbcheck shows no errors, an ldbsearch is successful, and yet it's not possible to start the AD properly. What else is there that

hi, After an update to our DC4, I started to notice the error "Failed to store repsFrom - Indexed and full searches both failed!" in the logs. root at dc4:~# tail -f /var/log/samba/log.samba Copyright Andrew Tridgell and the Samba Team 1992-2023 [2023/12/05 14:09:06.191978, 0] ../../lib/util/become_daemon.c:150(daemon_status) daemon_status: daemon 'samba' : Starting

The two systems I'm referring to are on different domains, different locations. No connection whatsoever except me being the one administering both. According to oEMInformation the server was provisioned by 4.3.3. I just checked the Samba log file and it seems that version 4.7.4 was running before the update. I'm now looking at the logs right before the upgrade and indeed, there have

Any thoughts? :D On Tue, Dec 5, 2023 at 4:59?PM Elias Pereira <empbilly at gmail.com> wrote: > hi, > > After an update to our DC4, I started to notice the error "Failed to store > repsFrom - Indexed and full searches both failed!" in the logs. > > root at dc4:~# tail -f /var/log/samba/log.samba > Copyright Andrew Tridgell and the Samba Team 1992-2023 >

"Indexed and full searches both failed" is not a good sign. Failed in this case doesn't just mean 'returned no results', it means 'database error'. It could be on any record, as the filtering for a full search has to happen across the whole DB and if any of those filter tests fail, it will do this. I think you have another working DC, if so I would demote this

hi, My saga continues... I've configured the audit log for drs_repl in smb.conf, and below is the log generated. https://transfer.sh/7fen4qCNIQ/drs_repl.log The log level was 5. drs_repl:5@/var/log/samba/drs_repl.log Could someone take a look and help me understand the log? On Sat, Feb 10, 2024 at 11:29?AM Elias Pereira <empbilly at gmail.com> wrote: > Hi samba list!!! > >

Hi samba list!!! Douglas, /usr/sbin/samba_kcc is made in python. Does it have a link to source4/dsdb/kcc/kcc_periodic.c which is made in C? The errors that appear in my DCs have their output in the C code. Correct me if I'm wrong, but I read in some old posts on the list that samba would have a new code for kcc (python code?), which would be closer to what M$ uses. Could this have anything

I've been grappling with a recurring set of errors for quite some time now: - UpdateRefs failed with NT_STATUS_IO_TIMEOUT - Failed samba_kcc - NT_STATUS_IO_TIMEOUT - IRPC callback failed for DsReplicaSync - NT_STATUS_IO_TIMEOUT Despite cranking up the log level to 10, the returned information remains frustratingly cryptic and hard to decipher. This error, being overly generic, continues to

Either the local server is busy, or possibly (but it would not explain the samba_kcc) Samba's drepl process is stuck talking to a remote server. Is the drepl local processes very busy doing inbound replication? My instinct is either the server is very busy (and this should show up in CPU use) or a transaction is being held open excessively. Andrew Bartlett On Sat, 2024-03-09 at 19:11 -0300,

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

> > Is the drepl local processes very busy doing inbound replication? How can I check this? My instinct is either the server is very busy (and this should show up in > CPU use) or a transaction is being held open excessively. I use VMs on Proxmox. In DC1, I installed the Proxmox agent, and CPU usage via the dashboard is very low. However, when I checked using 'top,' the LDAP

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

> > There is probably nothing wrong with your log, but Firefox doesn't > like it, it thinks it contains a virus. I just saw now that your response ended up in spam, probably because of the link with the log. O.o I still receive the error in the logs: source4/dsdb/kcc/kcc_periodic.c:790: Failed samba_kcc - NT_STATUS_IO_TIMEOUT The strangest thing is that it occurs when the command

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

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

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