1

I am trying to transfer a large file between two remote hosts (both on different subnets). I found this command to work the first time:

scp -3 root@foo:/path/to/largefile user@bar:/path/to/where/it/should/go/

The command worked the first time, now when I attempt to run it again to transfer the other files, it never transfers. Instead I get a prompt for a password and then it exits with an exit code 1. Running -v gives me:

debug1: Sending command: scp -v -f /run/sr-mount/3e3a905f-28ad-01b4-d50a-1ffe151ed28a/debian-8.8.0-amd64-CD-1.iso Sending file modes: C0644 660602880 debian-8.8.0-amd64-CD-1.iso Sink: C0644 660602880 debian-8.8.0-amd64-CD-1.iso debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2480, received 2372 bytes, in 0.1 seconds Bytes per second: sent 32882.6, received 31450.6 debug1: Exit status 1 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2904, received 2964 bytes, in 3.3 seconds Bytes per second: sent 893.5, received 912.0 debug1: Exit status 1

Can someone tell me why all of a sudden this command no longer works? I checked /var/log/syslog and couldn't find anything..

Improve this question

1 Answer 1

Reset to default
2

You can use -vvv to get more information from the log. But problem with -3 is that you can not reasonably get any debug information about the errors from the remote sides (upstream bug with patch). The err messages are being send from one remove side to the other and there is no place to display them (without introducing some complexity).

To get an idea what could go wrong is probably easiest to make sure that the source file is properly readable (and there is no typo in the name) and the target folder is writable, there is enough of disk space and so on:

ssh root@foo stat /path/to/largefile ssh user@bar stat /path/to/where/it/should/go/

Other possibility is to build OpenSSH from source and apply the above linked patch. It should print the errors in the client (It should be enough to do that only on your machine).

Or just use rsync, which is more suitable for performance, throughput and usability.

Improve this answer
3
  • Would it be possible for you to provide an example of using rsync? I tried it before with flags -vuar, but it didnt work and mentioned it cannot transfer from remote server to remote server. Commented May 26, 2017 at 14:42
  • This answer is giving nice example how it can be done with rsync and port forwarding: unix.stackexchange.com/questions/183504/… Commented May 26, 2017 at 14:44
  • Thanks for your help.. I cant get a tunnel going. Most likely because both servers are in different subnets... I guess I will have to scp the file to my local PC and then scp it again to the other server.. Commented May 26, 2017 at 15:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.