[Samba] Poor performance on open/copy/close/rename file operations via remote/VPN connection

[gianfranco pra floriani]

Hello Udo,

Udo Rader wrote:
> On Wed, 2008-03-26 at 10:47 +0100, gianfranco pra floriani wrote:
>   
>> Udo Rader wrote:
>>     
>>> On Mon, 2008-03-24 at 22:30 +0100, gianfranco pra floriani wrote:
>>>   
>>>       
>>>> Hello,
>>>> I have Samba version 3.0.24 running on a 2.6.14-gentoo-r5 x86 kernel 
>>>> (xeon 3ghz, 1gb ram raid 5).
>>>> All clients accessing samba shares via LAN have no problems. Samba 
>>>> server works perfectly and fast.
>>>> We are instead experiencing serious performance issues when accessing 
>>>> samba shares from remote clients (WAN), via VPN.
>>>> Simple operations like "open a file", "copy & paste a file", "save a 
>>>> file" from Windows XP SP2 clients are incredibly slow. It may take 10 
>>>> seconds to open a "save as" dialog box, and maybe 15 more seconds to 
>>>> save a "hello world" txt file from Notepad.
>>>> Other services using the VPN such as SCP, SSH, HTTP, FTP work very
>>>> good 
>>>> on the same connection, with no slow issues at all. I tried 2 kinds
>>>> of 
>>>> VPN connections (OpenVPN and a router-proprietary VPN 
>>>> gateway-to-client), and both have the same issue, both only with
>>>> Samba.
>>>> I wonder if there is something I'm missing in client or server 
>>>> configuration that makes Samba talking very slow when connections are 
>>>> not coming from the LAN. The file transfer process works fine: once
>>>> the 
>>>> "saving file" or "copying file" process has begun, it takes the same 
>>>> amount of time needed by a SCP or a FTP transfer command using the
>>>> same 
>>>> VPN connection. I tried to copy a 2MB file from client to server and
>>>> the 
>>>> time needed using SCP and using SAMBA (once the copy process was 
>>>> started) was the same.
>>>> I tried to add some "socket options = TCP_NODELAY SO_SNDBUF=8192 
>>>> SO_RCVBUF=8192" in smb.conf with no results.
>>>> The problem is the same using "explorer", command prompt, or any
>>>> program 
>>>> in the client. We currently use all XP SP2 clients.
>>>> It looks like the initial and final talking acknowledgement between 
>>>> client and server for any kind of operation is unacceptably slow,
>>>> while the file transfer process seems not to be involved in this
>>>> problem.
>>>>     
>>>>         
>>> This is quite common with VPN connections. What response time do you get
>>> from a ping (LAN vs. VPN)?
>>>
>>>   
>>>       
>> Hello Udo,
>> this is a ping from the server to a client:
>> PING 10.0.0.190 (10.0.0.190) 56(84) bytes of data.
>> 64 bytes from 10.0.0.190: icmp_seq=1 ttl=128 time=52.7 ms
>> 64 bytes from 10.0.0.190: icmp_seq=2 ttl=128 time=48.9 ms
>> 64 bytes from 10.0.0.190: icmp_seq=3 ttl=128 time=49.2 ms
>> from client to server the ping time is the same.
>>     
>
> doesn't look too bad.
>
>   
>>> A major network performance for VPN clients is the correct configuration
>>> of various networking parameters (such as MTU, window size, etc. - all
>>> depending on the type of internet connection you have).
>>>
>>> And finally, what type of VPN are you using?
>>>
>>>   
>>>       
>> we have ssh, scp, ftp and http services running on the same VPN  
>> (OpenVPN 2.0.6 i686-pc-linux-gnu), and all services are running fine, no 
>> delays, no bottlenecks. Samba is the only service having problems.
>>     
>
> Are you sure that it is a samba problem? Try to create a share on a WXP
> LAN box and try to access it from a remote box.
>
> Your problem is very likely a SMB (and not samba) problem.
>
>   
Ok, I created a WXP LAN box share and accessed from a remote box: Same 
old story: SLOW!
> And what type of OpenVPN adapter do you use? tun or tap?
>
>   
dev tap0
proto udp

As you point out, it looks more a SMB (and not samba) problem.

I will now try to discover the problems and let you know.
Any hints will be really appreciated.

Thank you very much
gian


(PS: To make a further test, I installed webdrive, it maps a FTP 
connection to a network drive letter.. a true beautiful speed, almost as 
fast as being in LAN)