11

I can't think of any reason why the transfer of a simple file with rsync -e 'ssh -p 19' -vvv /path/to/file [email protected]: fails with 

opening connection using: ssh -p 19 -l root 192.168.179.3 rsync --server -vvve.Lsfx . .  (11 args)
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]
[sender] _exit_cleanup(code=12, file=io.c, line=226): about to call exit(12)

when ssh login ssh -p 19 [email protected] works fine. cat [/path/to/file] for the local file suceeds and permissions are 664 and owner is the user invoking rsync. The file is located in /tmp/.

Specifying the absolute path in the -e argument, i.e. rsync -e '/usr/bin/ssh -p 19' -vvv /path/to/file [email protected]:, doesn't help.

I'm using rsync 3.1.1 on Ubuntu 15.10.

Improve this question
2
  • 1
    Maybe related to this: stackoverflow.com/questions/7261029/… Commented Dec 24, 2015 at 22:53
  • @nKn Thanks, that wasn't it, but pushed me in the right direction (see answer below). Commented Dec 24, 2015 at 23:48

3 Answers 3

Reset to default
34

Another possible interpretation of ssh or rsync giving Permission denied, please try again.. The reasons is that the remote rsync is in an unusual location and has to be specified with --rsync-path on the sender side (see https://stackoverflow.com/questions/7261029/how-to-solve-rsync-error-error-in-rsync-protocol-data-stream-code-12-at-io-c#comment22193023_12286054).

Dear ssh devs, please stop this nonsense! The number of error cause which trigger Permission denied, please try again. grows and grows, please find it in your heart to provide users with any usable feedback - you didn't implement anything in this direction so far which I'm telling after using ssh for years now and encountering dozens of very clear and explainable reasons for failures which just end up in Permission denied, please try again.. No one can understand that!

The fact that the OS produces this message and can't be change doesn't mean anything. You're responsible for the feedback your software provides to the user and if Permission denied, please try again. is given for the very easy to communicate reasons of failure above something is very wrong - just print remote binary not found, please use --rsync-path on the sender side instead! See, that wasn't so hard.

Improve this answer
4
  • 5
    It's not that the remote rsync is in an unusual location. It is that it is in a different location than the local one. In my case remote was in /usr/bin, which is hardly unusual, local was in /opt/usr/bin. Commented Nov 26, 2018 at 12:12
  • 1
    I agree, terrible error message! Mine was in /bin/rsync on the remote and /usr/local/bin on the local. Commented May 16, 2020 at 20:33
  • this also helped me just now, thanks! doing a rsync to my synology box and rsync was indeed in /bin/rsync rather than where it was expecting it to be Commented Dec 11, 2023 at 17:19
  • OMG! How did you even figure that!!! Thank you. Commented Sep 20, 2024 at 21:25
3

The error message doesn't say anything about file permissions. Rather, it's the standard ssh error message saying that the login itself was not allowed – either due to wrong password, or the server configuration disallowing logins by root.

Note that there are several differences between your "test" and the rsync command:

  1. You ssh to [email protected], while rsync is connecting to [email protected].
  2. You do not specify a port, thus connecting to standard SSH port 22, while rsync has the port 19 specified. It is possible that these ports are handled by two separate sshd daemons, with different configurations.
Improve this answer
1
  • I just pasted the output of the wrong command, sorry. Of course, I'm connecting to 192.168.179.3 on port 19, not 1.2.3.4 on port 22. There's no daemon listening on port 22. Login by root to 192.168.179.3 on port 19 works. Commented Dec 24, 2015 at 22:27
0

Just putting my solution here in case it's useful for anyone else.

I was trying to use rsync to copy files to an EC2 instance. The same command had been working fine for a good while, but then broke. None of the solutions I found online really helped.

By ssh-ing into the remote server and running ls -l in the location I was copying to, I found that the build folder had been created by root while all the others had been created by ubuntu. The permissions issue came from trying to copy my local build folder to the remote, so removing the local build folder (which shouldn't have been getting copied anyway) solved the problem for me.

Improve this answer

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.