This is a discussion on Re: [Samba] Poor performance on open/copy/close/rename file operations - Samba ; 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 ...
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:
>>>> 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
>>>> on the same connection, with no slow issues at all. I tried 2 kinds
>>>> VPN connections (OpenVPN and a router-proprietary VPN
>>>> gateway-to-client), and both have the same issue, both only with
>>>> 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
>>>> "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
>>>> VPN connection. I tried to copy a 2MB file from client to server and
>>>> 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
>>>> 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
>>> 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?
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
(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)
To unsubscribe from this list go to the following URL and read the