Slow initial response on idle share

Kenneth Porter shiva at well.com
Fri Feb 26 05:54:39 GMT 1999


On Fri, 26 Feb 1999 00:07:44 +0100 (CET), Robert Dahlem wrote:

>On Thu, 25 Feb 1999 21:51:35 +1100, Kenneth Porter wrote:
>
>>>>I've noticed that when a mapped drive is left idle for awhile (OS/2
>>>>Warp 4 or NT4WS client) that an operation on that share (eg. a
>>>>directory listing) will take several seconds to complete. After that,
>>>>operations will again be responsive until the share is once again left
>>>>idle for a long period. I'm not sure how long it takes to become slow
>>>>again.
>>>
>>>This looks like you have set up "dead time" in smb.conf with something not 
>>>equalling zero. Samba disconncts the client after "dead time" minutes from the 
>>>share (only when no files are open on the share) and the client later has to 
>>>reconnect.
>>
>>Just checked, and deadtime (as documented in "man smb.conf") isn't in
>>there. According to the man page, it defaults to zero (ie. no deadtime
>>checking). Could smbd have been compiled with some non-zero default?
>>How would I determine this?
>
>Run testparm, it will tell you.
>
>Just to go somewhat further into details: Can you try to run smbstatus before 
>doing the first operation you expect to respond slowly? Do you see your share 
>being connected? Afterwards?

If I remove the deadtime setting from smb.conf, testparm claims it's
zero. Now that I've set the deadtime to zero, it looks like the problem
has gone away. I poked around in the source RPM (RH5.2 distribution),
and it looks like the default is zero, so I'm at a loss to explain the
observed behavior.

Is it possible that it's related to a non-zero user level or password
level? I originally had these set to handle some mixed-cased names and
passwords, before going to encrypted passwords. I turned on encryption
support and this solved a lot of my NT access problems, but I didn't
immediately remove the user/password level options. At the same time I
set deadtime to zero, I commented out the level params, so perhaps
that's what speeded things up. What's puzzling is why they should be
relevant if encrypted passwords are in use.


Ken
mailto:shiva at well.com
http://www.well.com/user/shiva/

http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)



More information about the samba mailing list