Re: 6s Delay when accessing share
On Tue, 7 May 2002, Christoph Kaegi wrote: On 2002.05.07 04:46, Richard Sharpe wrote: What version of Samba? Have you made any mods to Samba? 2.2.4. No mods. OK ... Configured with # ./configure --prefix=/usr/local --with-quotas --with-msdfs --with-included-popt --with-acl-support OK ... The trace seems to show that your client is trying to access \private\desktop.ini, which fails in wierd ways (STATUS_INVALID_HANDLE), even though the file was opened successfully. Well, this is actually another problem I introduced (I believe) by having 'nt acl support = no' on the homes share. I corrected this and uploaded a new logfile/trace/smb.conf to www.zhwin.ch/~kgc I will pull this down tomorrow and look at it. The client then tries to do a bunch of RPCs, all of which fail trying to bind to the RPC operation with the same status. This is the actual problem, causing the delay of 6 to 10 seconds. I tried the same with a Windows 2000 client. I think there were the same problems, but the client didn't try that long, so the delay wasn't as annoying. Hmmm, do you have a trace of that as well? Comparisons are good :-) What does the log.$client or log.smbd show with respect to these? It tries to bind to the pipe \srvsvc and fails with the same response all the way to the end of the trace. ... log.smbd doesn't contain anything recent or interesting and OK, Thought as much, because most useful data goes in log.$client: where is this file? log.$(client-name), ie log.fred, where fred is the client name (tied to log file = /var/log/samba/log.%m) ... Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: 6s Delay when accessing share
On 2002.05.04 04:34, Richard Sharpe wrote: Well, all of the stuff you talk about below is actually RPC traffic. So, the question is, why does it need to do this stuff prior to copying a file to a share or accessing a share. Do you have a trace that you want to share [pun intended] around? Yes, there is a snoop trace at: www.zhwin.ch/~kgc/accessToMyDocuments.snoop.gz Regards Chris -- -- Christoph Kaegi [EMAIL PROTECTED] --
Re: 6s Delay when accessing share
On Mon, 6 May 2002, Christoph Kaegi wrote: On 2002.05.04 04:34, Richard Sharpe wrote: Well, all of the stuff you talk about below is actually RPC traffic. So, the question is, why does it need to do this stuff prior to copying a file to a share or accessing a share. Do you have a trace that you want to share [pun intended] around? Yes, there is a snoop trace at: www.zhwin.ch/~kgc/accessToMyDocuments.snoop.gz Hmmm, I have looked at this trace (Ethereal is great), and it is very interesting. What version of Samba? Have you made any mods to Samba? The trace seems to show that your client is trying to access \private\desktop.ini, which fails in wierd ways (STATUS_INVALID_HANDLE), even though the file was opened successfully. The client then tries to do a bunch of RPCs, all of which fail trying to bind to the RPC operation with the same status. What does the log.$client or log.smbd show with respect to these? It tries to bind to the pipe \srvsvc and fails with the same response all the way to the end of the trace. ... Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: 6s Delay when accessing share
I am actually a little in distress about this one.
They want to replace our main samba fileserver with a W2k one,
if I can't get it to play nice with our new environment.
So, if anyone could give me a hint, in what direction
I can investigate further, I would be *very* grateful.
Thanks
Christoph
On 2002.05.02 11:45, Christoph Kaegi wrote:
We experience a 6 seconds delay when accessing a samba share, for example
when copying a local file to the share, or accessing the share by
doubleclicking on my documents, which is redirected to the UNC sharename.
When looking at the network traffic, i see the following:
- client is doing a create request to \srvsvc on the IPC$ Share
- this succeeds and the client gets a FID
- client does a DCERPC Bind (UUID: 4b324fc8-1670-01d3-1278-5a47bf6ee188)
- now, the server responds with a 'Write AndX Response'
Error: STATUS_INVALID_HANDLE
- client tries do close the FID but gets again a STATUS_INVALID_HANDLE
This is repeated for about 400 to 600 packets, then the original
user request for copying or showing a share succeeds.
I can send a tcpdump of this, if it helps.
Our configuration is as follows:
Server:
- Sun Solaris 8 / Sparc
- Samba 2.2.3a
- smb.conf entry for the share:
8
[homes]
comment = Home Directory M:
path = %H
read only = No
create mask = 0755
browseable = No
8
- this server is authenticating via NTLM to a W2k Active Directory
- Usernames/Groups are resolved via nss_ldap
(http://www.padl.com/OSS/nss_ldap.html)
Client:
- Windows XP professional
- 'My documents' redirected to the UNC path of the homeshare
I gladly provide more information, if needed.
Can anyone explain, what Windows ist trying to do with those
requests?
Is it possible to get rid of this delay?
[...]
--
--
Christoph Kaegi [EMAIL PROTECTED]
--
Re: 6s Delay when accessing share
Pleas try asap 2.2.4 there have been merged in several patches that solved some file transfer problems. On Fri, 2002-05-03 at 12:16, Christoph Kaegi wrote: I am actually a little in distress about this one. They want to replace our main samba fileserver with a W2k one, if I can't get it to play nice with our new environment. So, if anyone could give me a hint, in what direction I can investigate further, I would be *very* grateful. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
