scp stalled while copying large files

Question

According to the needs of the experiment, I set the MTU to 8000. After doing this, when I use scp to copy large files, it stalled with 0.00%. I tried scp -l or scp -C and turning tcp_sack on/off, but it still didn't work. And I can't change the MTU size for experiment result comparison. Is there any other way to help?

score 106 · Answer 1 · edited May 23 '17 at 10:31

An attempt at a comprehensive solution, as there could be several problems and limitations depending on your situation.

rsync

My preferred option: using rsync doesn't give this problem and is a bit more versatile in my opinion, e.g. it keeps track of which files are already there, so if the connection ever does break it can pick up from where it left off - try the --partial flag too - among other things.

Instead of

scp local/path/some_file usr@server.com:"/some/path/"

you can just do

rsync -avz --progress local/path/some_file usr@server.com:"/some/path/"

I've tested this on several occasions when scp would give me the same problem it gave you - and now I just use rsync by default.

Limit speed

Not a solution for OP as the MTU is fixed in this situation (and probably not the issue here), but if the culprit is a slow/unreliable connection between the two drives, setting a speed limit reduces the delays which make the TCP connection stall - at the expense of a slower transfer of course. This is because scp grabs all the bandwidth it can get unless you specify the maximum data rate in kilobits, like so:

scp -l 8192 local/path/some_file usr@server.com:"/some/path/"

This doesn't always work though.

Compression option

scp's -C option can speed up the transfer, reducing the probability that the transfer stalls.

Disabling TCP SACK

As mentioned by the OP, and here.

sudo sysctl -w net.ipv4.tcp_sack=0

(or similar)

LAN card MTU

Again an MTU fix, not necessarily of the transfer specifically though:

ifconfig eth0 mtu 1492

or on newer (Linux) systems:

ip link set dev eth0 mtu 1492

Other

If all else fails, this lists another handful of potential solutions not included here.

The more exotic hpn bug may be at fault too.

Yes, works perfectly. In fact I always use it now, also for 'local' files, e.g. if I'm writing to a mounted (networked or even USB) hard drive. Saves much of the pain of drag and drop, which in Mac OS X Finder often fails at the last possible moment. — BrechtDeMan, Jun 21 '16 at 12:39
This also fixed my issue of sudo apt-get update bombing out. Nice one. — Tisch, Sep 27 '17 at 18:29
Just make sure that you are modifying the properties of the right interface. For me sudo ip link set dev ens3 mtu 1492, fixed the issue for me. Thanks. — Rakesh Gupta, Aug 12 '19 at 15:42

score 0 · Answer 2 · answered Aug 04 '20 at 11:32

Although this question is quite old, I still want to share another possible solution in addition to the nice list @BrechtDeMan already provided.

In some cases the problem might be caused by a invalid speed/duplex configuration of the used link, set by auto-negotiation. My device e.g. was running with 100 Mbps/full-duplex by default but did not properly work with this configuration.

So you might read the current configuration and the supported modes with:

ethtool eth0

and give it a try with a lower setting, e.g. 100 Mbps/half-duplex in my case:

ethtool -s eth0 speed 100 duplex half

score 0 · Answer 3 · answered Oct 28 '22 at 17:53

0

When I used git bash's scp to copy a remote 6 gigabyte file to Windows, it repeatedly stalled/hung at 99%. But when I used Ubuntu on Window's scp, it succeeded the first time.

answered Oct 28 '22 at 17:53

Don Smith

473
4
10

score -1 · Answer 4 · answered Jan 15 '15 at 11:31

Any chance you're behind a Cisco ASA firewall? If so, turn off "sequence number randomization" and that'll help a lot -- also disable TCP Offload (ethtool -K $INTERFACE tso off gso off gro off) if you're on a Cisco ASA with Broadcom NICs in your server.