Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

This may be the most ridiculous question I've ever asked, but I freely admit that I am stumped. I'm trying to move some files from a remote server to my local machine. I'm running Ubuntu, obviously. Now, just for background this machine has two different users. I'm logged in as one of them; joe. So when I click the home folder in Unity I get my joe home folder with all of my sub folders and files. One of the folders that I have inside joe is called remote. Inside remote is another folder named mail. I have no problem logging into the remote server using either openssh or putty, but I cannot copy the files to joe/remote/mail. For some reason I keep getting the path wrong and I have tried every variation that I can think of. A partial list would be...

/joe/remote/mail
/remote/mail
~/joe/remote/mail
~/remote/mail
remote/mail
joe/remote/mail
/home/remote/mail
/home/joe/remote/mail
/local/home/joe/remote/mail
/local/joe/remote/mail
/local/remote/mail

You get the idea. Everything I try comes up with the same error: folder xxxx does not exist. I guess what I'm asking here is just what, exactly, does openssh and putty think is the current directory on the local machine? I have searched online documentation and have found nothing that tells me this simple and infinitely usable piece of information.

Also, I went ahead and copied the files using "." as the destination, which should copy them to the current directory on the local machine. It worked! But... where are they? They aren't in root. They aren't in Home. They aren't in joe. I'm lost.

Edited to add that I am using scp to copy the files, if that matters.

share|improve this question

4 Answers 4

up vote 1 down vote accepted

A scp command line looks in principle like this:

scp options from to

Ignore the options for now (they are optional anyway); you can read about them using man scp.

scp supports local and remote filenames both for the from and to part. Local filenames are just regular file or directory names, like:

 /home/joe/
 /home/joe/remote/mail
 /home/joe/remote/mail/inbox

Remote file names consist up two or three parts:

  • An (optional) user name
  • The remote host name
  • The path on the remote host

A remote filename is constructed using these parts like this

 remote-host:/path/on/remote/host
 user@remote-host:/path/on/remote/host

If you want to copy all files from your local directory "/home/joe/remote/mail" to the directory "/opt/backup/joe/mail" on a second server "other", using the username "admin", you issue the following command:

 scp -r /home/joe/remote/mail admin@other:/opt/backup/joe/mail

(The -r means recursive copying of directories)

If you want to copy all files under "/var/spool/mail/joe/" from the remote server "other", using username "admin", into your local folder "/home/joe/remote/mail", you issue the following command:

 scp -r admin@other:/var/spool/mail/joe/ /home/joe/remote/mail 
share|improve this answer
    
Your last line... scp -r admin@other:/var/spool/mail/joe/ /home/joe/remote/mail ... is exactly the command I used first. I always give me an error that /home/joe/remote/mail does not exist. As I said in the original post, every variation of paths that I can think of yields the same error message –  Blind Fish Jul 12 '12 at 17:28
    
@BlindFish does the path /home/joe/remote/mail really exist on your local machine? –  daniel kullmann Jul 12 '12 at 17:56
    
Seriously? Wow. –  Blind Fish Jul 12 '12 at 18:04
    
@BlindFish Sorry, it's the only thing I can think of right now; I use such commands almost every day. You're sure there were no typos involved? –  daniel kullmann Jul 12 '12 at 18:08
    
@BlindFish Just to make sure: you're running your commands as user joe, right? –  daniel kullmann Jul 12 '12 at 18:09

Most of the confusion from a SSH session may arise from the fact that we always have to be aware of three locations to get the commands right.

In the following I will refer to @home as the place where we actually physically sit and to @remote as the machine we SSH to. As soon as we have opened a SSH session on the remote machine the terminal will execute all following commands on the remote machine. This is visualized by the prompt:

  • admin@home:~$: we sit in our home machine in the HOME directory

  • user@remote:~S: we are logged in as user in his HOME on the remote machine

What we want:

In case we want to copy files from the remote to our home we have to be aware of where we sit, i.e. on which machine the command will be executed:

admin@home:~$ scp user@remote:/remote_path/source.file /home_path/

will execute scp command on our home machine to copy source.file from the remote_path on the remote machine to the home_path in our home machine.

What we probably don't want

If we executed the following:

admin@home:~$ ssh user@remote
user@remote:~$ scp user@remote:/remote_path/source.file /home_path/

it will not quite be what we intended in that then scp was executed on the remote machine to copy the source.file to the /home_path on the remote machine. To make the source and destination clear we would issue

user@remote:~$ scp user@remote:/remote_path/source.file admin@home:/home_path/

Then source.file would be indeed be copied to home_path but only if the remote machine (where scp is executed) can open a SSH session to our home machine.

We could further extend the usage of scp to copy files from one remote1 machine to another remote2 machine by:

admin@home:~$ scp user1@remote1:/remote1_path/source.file user2@remote2:/remote2_path/

Advanced copy using rsync

As scp has some limitations we may want to use rsync to copy files instead. Here is an example how this would be invoked:

admin@home:~$ rsync -avze ssh user@remote:/path/source_dir/ /path/destination_dir

This will exactly clone all files from the remote source_dir to the destination_dir on our home machine.

share|improve this answer
    
What you are saying seems infinitely more logical than most, but everything I see on ssh uses the /home/path or /local/path rather than user@home/path syntax. Having said that, I've tried using the user@home/path syntax and I still get the no such file or directory exists error. What may be tripping me up is the actual specific syntax for "user@home". For instance, I am user "joe" on a machine named "hal". Would I be using "joe@hal/path" or "joe@home/path" or "joe@local/path", or what? I've actually tried all three of those and still get the no such file error so I'm still a bit lost. –  Blind Fish Jul 12 '12 at 13:47
    
@BlindFish: it may likely be joe@hal:/home/joe/directory when viewed from "@home" for the scp command but it may just be /directory when you are actually logged in a SSH session on the remote machine. Watch out for your terminal prompt - its then joe@hal:~$ (where ~ is the same as /home/joe/). Try to cd directory from the SSH session and see your prompt turn into joe@hal:~/directory$. –  Takkat Jul 12 '12 at 14:00
    
I can't cd out of the ssh session. It just takes me back to root on the home machine and then stops. The only way I can go back to the local computer is to kill the ssh session. However, just for what it's worth, when I open the terminal it does open to my home folder with the prompt joe@hal:~$ Since I start the ssh session from this prompt it is only logical that this is where the ssh session would look back when trying to copy locally. Still, I get no love from it at all. –  Blind Fish Jul 12 '12 at 17:32
    
@BlindFish: you may need some experimenting to get the idea. Why not open two terminal sessions, one SSHed to the remote, the other for local commands? –  Takkat Jul 12 '12 at 17:42
    
I am beginning to think that this may be a connection issue. I completely understand that I am clueless on ssh but I am trying to hack my way through this using various manuals and more and more it seems this problem should not be happening. I've tried two other things, both of which gave me odd failures. First I tried scp -r root@<domainname.com>:/var/spool/vmail joe@<ip address of local machine>:/remote/vmail and I received an error that I could not connect to the ip address. Running out of characters, will detail second in after this comment. –  Blind Fish Jul 12 '12 at 17:53

openssh defaults to the home directory of the user in question.

Try using the sudo updatedb followed by locate filename to locate any files.

share|improve this answer
    
If that were the case then /remote/mail would not have thrown an error, correct? –  Blind Fish Jul 12 '12 at 4:03

With scp, you need to give the remote machine name like:

scp /path/to/file-to-copy joe@hostname:/home/joe/remote/mail/

Assuming your are SSHed in the remote machine and want to copy to joe user on your local machine. hostname is the name of your local machine (can be an IP too but in both cases, it has to be accessible from the remote machine).

You can invert the situation too (to use with a VPS for example from where probably your local machine won't be accessible) and do from your local machine:

scp login@remote-machine:/path/to/file/to/copy ~joe/remote/mail/

OBS: when you SSH to a machine the terminal is on the remote machine and "has no idea" of what is your local machine and can't access it without its hostname. Also you need to have a route to access your local machine from the remote one (you can try it with ping to your local machine).

When you copied the files to "." they were copied to the directory you were at that moment in the remote machine.

UPDATE:

Hostname is only machinename or machinename with domain like machinename.domain.com but this will only work if you can reach yur local machine from the remote machine (your local machine has a public IP (and DNS record) if remote is via internet or some kind of local name resolution (DNS for example) if both machines are on the same network.

Hostname can be an IP also if you don't have a name resolution system to your machine but the machine are in the same network or you are working with public IPs.

As you can't ping your machine from the remote machine, I think you have no way configured to reach it and you should use the inverted solution proposed above not doing SSH to the remote machine and copying with SCP from your machine as your remote machine is reachable (you can SSH into it).

To explain a point of the syntax: user@something is a login to the machine and something has to be a hostname not a directory. So joe@home/... won't reach anything as home is a directory and you cannot login a directory.

share|improve this answer
    
I tried this. I tried ~joe/remote/mail/ I tried joe@<machinename>/remote/mail/. I tried ~/remote/mail. I just tried all of those three again. Same result. No such file or directory exists. –  Blind Fish Jul 12 '12 at 5:12
    
if you are SSHed in the remote machine AND you can ping you local machine with ping hostname, the correct path is joe@hostname:~/remote/mail or joe@hostname:/home/joe/remote/mail. If you can't ping your machine from SSH, you have to use the inverted way I described in the answer (copying from your local machine). –  laurent Jul 12 '12 at 5:20
    
Perhaps I am confused by "hostname". I have been using the machine name as it appears when I open terminal "joe@machinename:" Is this what you mean? If so, I cannot ping the local machine by machine name, or by joe@machinename. Can you clarify this a bit for a total ssh noob? –  Blind Fish Jul 12 '12 at 5:32
    
Updating answer –  laurent Jul 12 '12 at 13:47
    
If you want, give me the command you issue to access your remote machine with SSH and I'll show you the scp command so you can deduct how it works from it. –  laurent Jul 12 '12 at 14:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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