13

I'm using smbclient to transfer a set of large files (80 GB) nightly from a Linux system to a Windows share. Lately, for whatever reason, I've been getting I/O timeouts:

cli_push returned NT_STATUS_IO_TIMEOUT

which causes the active file transfer to be aborted and deleted from the Windows share.

This may be due to unresolved Samba bug 8498 (or maybe not). The Windows system is not under my control, so I can't install an SSH server (to use SCP or SFTP), and I do not want to depend on Microsoft's implementation of NFS.

Is there another simple, standard alternative that would let me move 80 GB of data reliably from Linux to Windows over the network on a regular basis (the network is GB Ethernet, so bandwidth isn't a problem)?

2
  • consider using tools such as rsync with partial mode enabled. Even WinScp should also help. Or provide a common NAS storage with NFS on Unix and CIFS on Windows, so no need to transferr at all incase if it is the same network. Best is to setup a torrent, incase the other network. ;-) Feb 17, 2012 at 12:55
  • just stumbled across "123go file transfer program" search on google Feb 17, 2012 at 12:57

6 Answers 6

11

Try using these socket options on smbclient

smbclient --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072'

I regularly copy 40+GB files from Windows to Linux media server without error, typical transfer rate is 85MB/s with machines connected via gigabit switch.

3
  • 1
    Thanks for this - this got rid of the error for me; and correctly copied a 2G file from a Ubunutu to a Windows Share.
    – monojohnny
    Jan 24, 2013 at 13:31
  • I've tried this and other variations of adjusting the values for SO_RCVBUF and SO_SNDBUF without luck. The file I'm trying to upload is about 8gig over a local network with zero packet loss.
    – mhvelplund
    Feb 29, 2016 at 8:16
  • specifying options SO_RCVBUF=xxxxx SO_SNDBUF=xxxxxx with any values reduces transfer speed in my env 10 times B-(. e.g. 15'000 down to ~1'600 KiloBytes/sec!
    – Fedor
    Apr 25 at 18:52
4

Using curl

I'm running smbclient version 4.9.4 trying to transfer a 97 MiB file from Arch Linux to Windows. Following the recommendation of user bsd, I called smbclient using

--socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072'

But this still failed with cli_push returned NT_STATUS_IO_TIMEOUT.

Fortunately, since version 7.40, curl supports the protocol version 1.

Thus, I used this to upload the moderately_sized_file from Linux to the service OurRemoteDirectory on the Windows machine at 172.16.17.52:

curl --upload-file /home/me/moderately_sized_file --user "OurWindowsDomain/MyUserName:MyPassword" smb://172.16.17.52/OurRemoteDirectory/Path/To/Dir/

For me, curl has uploaded the file reliably each time and also displays upload progress, which is nice.

Create the remote directory

Note that curl doesn't yet support creating directories on the remote host.

Consequently, you might need to create /Path/To/Dir/ using the following smbclient command:

smbclient //172.16.17.52/OurRemoteDirectory/ -U MyUserName%MyPassword -W OurWindowsDomain -c 'mkdir Path/To/Dir/'

In contrast to uploading the file with smbclient, smbclient mkdir has worked without an issue so far.

1
3

I had the same issue that download always failed, I was able to resolve the "parallel_read returned NT_STATUS_IO_TIMEOUT " problem using these options:

smbclient -m SMB2 ... -c 'timeout 120; iosize 16384; ...'

Example: from the file path "//server/share/My Files/More Files/version_1/file.txt"

smbclient -m SMB2 -N '//server/share' -c 'timeout 120; iosize 16384; get \"My Files\More Files\"\version_1\file.txt' -U <username>

Without these settings download failed 100% of the times and with these seetings it worked 100%.

2

I also had OP's issue using smbclient and the suggestions to use "--socket-options=" and "-t" didn't help.

I found the solution, for my use case, on a Google translated French site that suggested issuing the "iosize" command before issuing the "put" command.

In my scenario I'm piping data to smbclient through a fifo and using the -c switch to execute the "put" command. My code changed from:

smbclient \
        --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=16777216 SO_SNDBUF=16777216' \
        -E \
        "//${smb_endpoint}" \
        "${smb_password}" \
        -U "${smb_username}" \
        -c "put /dev/fd/0 ${index}.json.lzo"; echo $? >"${exit_file}"

to

smbclient \
        --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=16777216 SO_SNDBUF=16777216' \
        -E \
        "//${smb_endpoint}" \
        "${smb_password}" \
        -U "${smb_username}" \
        -c "iosize 16384; put /dev/fd/0 ${index}.json.lzo"; echo $? >"${exit_file}"

Note: iosize 16384; added before the "put" command.

I hope this saves someone some time.

1
  • specifying options SO_RCVBUF=16777216 SO_SNDBUF=16777216 reduces transfer speed 10 times in my env(. e.g. 15'000 down to 1'600 KiloBytes/sec!
    – Fedor
    Apr 25 at 18:44
0

Maybe you can install a ftp server on your linux server, and ask Windows admin to send it the file nightly ?

FTP has a some useful functions for transferring big files and a pause/resume mechanism. For file this big, you should take care to not have a network hardware shutting down inactive connections too early. It can close your control connection before transfert ends.

1
  • Files are going the other way, from Linux to Windows
    – Ex Umbris
    Feb 17, 2012 at 20:08
0

if

smbclient --socket-options='TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=131072 SO_SNDBUF=131072'

still returns cli_push returned NT_STATUS_IO_TIMEOUT

just add a timeout option -t <timeout in seconds>

It helps me to copy huge files ( > 200 Tb ) of virtual machines

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .