search for: skeet

skeet@Bridgewater.EDU wrote: > > > Basically what it looks like to me is that an smbd process is spawning a > child which goes defunct for some reason I have yet to determine and the > smbd process hangs out there waiting for the child. Of course the child is > never going to answer b...

I'm currently investigating the appearance of this error message for a significant number of our users' password change attempts. It would seem from my research that this error occurs when the data coming from the SamOEMhash function is not of the expected format/value. I do not know if this would be due to incorrect data being sent into the SamOEMhash function from the client or something

Have there been any problems reported with running 2.0.2 on servers using security=server with a 1.9.18p10 DMB? We've run into a situation where I've upgraded 4 of our servers to 2.0.2 but the DMB is still running 1.9.18p10. We have had sporatic trouble with the upgraded servers rejecting correct passwords because the DMB seemingly would not properly validate them. Today, we ran into a

In 2.0.4b using a 16-bit client (in this case Lanman for DOS), disk space reporting for partitions greater than 2GB always reports 0 space free. I've tracked this down to the disk_norm routine in the smbd/dfree.c file. In the code for adjusting block size and disk size/free values for 16-bit reporting, WORDMAX was incorrectly being multiplied by 512 before being compared with bsize. This

I saw a little discussion about this a few weeks ago but nothing concrete. We're running samba-1.9.18p8 under Solaris 2.6x86. I am periodically getting the following in the logfiles, usually _many_ at a time: 1998/11/03 14:42:00 request_oplock_break: no response received to oplock break request to pid 5411 on port 40884 for dev = 1980040, inode = 33c4d When I look up the PID (in this case