[Samba] Error was Transport endpoint is not connected

Gaiseric Vandal gaiseric.vandal at gmail.com
Tue Oct 12 08:23:53 MDT 2010

Is the Windows SQL server a domain controller or member server - I don't 
imagine it matters since this really does not seem to be an 
authentication problem (unless some cache has timed out-  which still 
should not affect users how have already authenticated.)  I am wondering 
there is some reauthentication that happens after 1 hour.

On the NAS device, there should be logs for each machine that has 
connected-  does that show anything?

When you backup the sql database, are you stopping sql and just copying 
the file ?  Are you using Windows backup?  Is this a scheduled or manual 

Are both machines on gigabit ethernet?  Do you see any windows messages 
about loosing connection with the domain server  (which can indicate an 
issue with autonegotiating ethernet speed or duplexing.)

Have you tried copying the 55 GB file from a XP machine to the NAS?

The other option may be to use scp or rsync to copy the file (if you 
have cygwin installed on your windows server.)

If my math is correct

     55 GBytes = 440 Gbits

At a 1 Gbit/sec that should be 440 seconds or 7.33 minutes.

On 10/12/2010 03:45 AM, robert.gehr wrote:
> I don't think this is my problem. Samba on the ReadyNas works all right,
> it is fast, I can mount shares etc. No worries at all.
> Only if I copy that huge file which takes abaut an hour (depending on
> the network load) or so the error pops up and the backup fails.
> The ReadNas is a Debian based Linux. The windows machine a "Server 2008
> R2" system. As already mentioned backing up to the old samba server
> never caused any troubles. Both the old samba server and the ReadyNas
> have the default smb ports = 445 139 settings.
> Both machines run as member servers of an AD Domain.
> Thanks again for any hints.
> Rob
> On Mon, 2010-10-11 at 16:47 +0200, Gaiseric Vandal wrote:
>> By default samba listens on two TCP ports-  445 and 139.  You can
>> specify this in smb.conf
>>           smb ports = 445 139
>> 445 is the newer smb  over tcp.    139 is the older smb over netbios
>> over tcp/ip.       445 was for Windows 2000 and newer clients..  I am
>> not sure why samba enables 445 by default since as far as I know it does
>> not support smb-over-tcp (without the NBT/netbios over tcp stuff.)    If
>> you  set "smb ports = 139" in your smb.conf you should see endpoint
>> messages disappear.
>> I think what happens is Win 2000 (and newer)  clients will initially try
>> to connect on port 445, find it isn't really compatible, and then "dump
>> down" to NBT on port 139.
>> So your NAS may be occasionally connecting on port 139 without problems
>> and occasionally connecting on port 445, and which point it fails.
>> OR-  the "endpoint" errors may be completely unrelated, but you just
>> don't look for when when the NAS is working.
>> Is the NAS part of the domain?  Is it a windows or linux/samba based device?
>> My samba server is a PDC.  XP clients in the domain connect with no
>> problems regardless of  if smb ports is 139 only or 139 + 445.   XP/Win7
>> clients NOT in the domain can't connect to shares if 445 is disabled,
>> which indicates they are connecting to 445 1st.
>> On 10/11/2010 08:57 AM, robert.gehr wrote:
>>> Hello All
>>> I used to back up a Mssql database (about 55GB) to a samba share without
>>> any problems. The samba server "Server-A" was running version 3.4.7
>>> We just got one of those "Netgear ReadyNas3200" things and I tried to
>>> backup up to a share there which sometimes works and sometimes not in
>>> wich case I get the following error:
>>> ----------------snip---------------
>>> [2010/10/08 21:32:26.937834,  0]
>>> lib/util_sock.c:474(read_fd_with_timeout)
>>> [2010/10/08 21:32:26.966404,  0]
>>> lib/util_sock.c:1432(get_peer_addr_internal)
>>>     getpeername failed. Error was Transport endpoint is not connected
>>>     read_fd_with_timeout: client read error = Connection reset by
>>> peer.
>>> ---------------snap-----------------
>>> The samba version on the ReadyNas is 3.5.4
>>> On the windows side nothing has changed apart form the destination to
>>> the new share. The ReadyNas performs pretty well and I do not get any
>>> network errors or otherwise. To rule out some network problem I exported
>>> a nfs share on the ReadyNas which I mounted on "Server-A", created a
>>> share on "Server-A" that points to the nfs-mount and ran a backup. No
>>> problems and no errors.
>>> Any ideas which buttons to push in order to get a reliable backup going
>>> again? From what I read this usually points to a problem on the client
>>> side but nothing has changed there. I could of course use the
>>> "Server-A:smb->nfs-mount:ReadyNas" solution but this is not what I want.
>>> Thanks
>>> Rob
> ------
> Everything should be made as simple as possible, but not simpler.
>                                                  ~ Albert Einstein

More information about the samba mailing list