When rsync'ing over SSH to a remote system, who does the remote system think I am? I would have expected that as I rsync'd to user@remote.host, and then typed in user's password for that machine, I would look like, and have the privileges of, user on that machine, just as if I had logged in over SSH as user.

I have a file server machine running Mint 18 with some Tbyte disks that I use as a backup/archive, and rsync to periodically from my Mint desktop. In order to rescue files from my son's viralised win10 laptop, I started it from a Mint stick and attempted to rsync files to the server, but it failed with a write premissions error.

Did it think I was user, or does my identity from the client machine contaminate things at all? I didn't attempt to troubleshoot, but simply used a USB HD instead. Before I do try to understand it (for next time) what should I expect? What should I have done?

closed as unclear what you're asking by rush, Rui F Ribeiro, Romeo Ninov, Timothy Martin, Isaac Jun 2 '18 at 12:55

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    It's not really clear what you're asking. Please add commands you tried to execute. With comments which one worked and which one didn't. And where what did you expect. Also mount options for the partitions you attempted to write on target machine will also be helpful. Otherwise we can simply make wild guesses. – rush Jun 1 '18 at 16:35

Assuming rsync over ssh,

  • An rsync target of remotehost: will use your local username to log in to remotehost unless the default has been changed in your local machine's ~/.ssh/ssh_config.

  • An rsync target of remoteuser@remotehost: will use remoteuser to to log in to remotehost.

  • I used the latter form of target. That's what I would have expected to have happened, which is why I was puzzled to have been refused permission. Now to try to replicate! – Neil_UK Jun 1 '18 at 19:36
  • 1
    Solved, it was the mount options, the target drive was unmounted. I was confused that the error message was 'refused permissions', which is why I was asking who it thought I was. – Neil_UK Oct 5 '18 at 7:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.