Can you create an ftp/ ssh tunnel to transfer files between VM and host machine?

Discussion in 'Linux Guest OS Discussion' started by mikelley, Sep 6, 2007.

  1. mikelley


    Essentially I am trying to find a away to efficiently transfer data between my laptop and the virtual machine I have setup with out the need to burns discs or create disk images.

  2. itsdapead


    Yup - three options. You'll need to do ifconfig on the Linux side to find out your VM's IP address - if you're feeling clever use NetInfo Manager to add a "machines" entry to give it a proper name (the Mac equivalent of editing /etc/hosts)*.

    1. SFTP/SCP - technically an overkill, because you are using encryption on a private "virtual" network between host and guest, and you might not get all the facilities of a full-blown network OS. However, its often the easiest thing to get going - and most Linux distros now install the servers for this in favour of the old non-encrypted FTP and telnet deamons. You might have to check /etc/ssh/sshd_conf to ensure that the SFTP subsystem is enabled*.

    On the Mac side, your choices are:
    (a) The command line sftp and scp commands (from the OS X terminal) - if you're a command-line junkie then set up password-free public key logins* and use scp. Most Mac users, however, will prefer something a bit GUIy

    (b) Fugu/Fetch etc. - free/shareware sftp clients.

    (c) MacFusion. (MacFusion seems to be the best "friendly" wrapper around MacFUSE and SSHFS)
    Mounts an SFTP share as if it were a regular disc - you access it via the finder.
    Note that this requires MacFUSE to be installed first - but if you have the latest version of Parallels then it already is. I'd recommend this, with the caveat that it seems to work nicely but I haven't really hammered it yet (*** see edit).

    2. Samba Also Known As (modulo pedantry) "Windows File Sharing", "SMB", "CIFS" etc. The server is an optional install on most Linux distros* - you may have to set up SAMBA passwords. On the mac side, Go -> Connect to Server -> cifs://

    You can reverse this and enable Windows File Sharing on the Mac, then mount your Mac disc from Linux (use the shell though - GUI file sharing in Gnome/KDE is a train wreck).

    3. NFS If you want to use NFS instead of Samba because its more "Unixy" and untainted by Microsoft then go ahead - technically it should be the most convenient way of sharing files between two trusted Unix-like systems, but it can be a pain to get going**. You'll probably want the shareware "NFS Manager" on the Mac side unless you enjoy messing around with NetInfo.

    * I'm sure there are copious "howtos" on these a mere Google away.
    ** HINT - you probably forgot to start portmap! :)

    *** (Edit) - just remembered one snag with MacFusion, though - it can't seem to deal with the "Unknown host" query you get the first time you SSH into a server, so its worth using Terminal and ssh to connect the first time, which will add the VM to your known hosts.
    Last edited: Sep 6, 2007
  3. Eru Ithildur

    Eru Ithildur

    But why ssh? You don't need any encryption if it is running locally...
    FTP is slow.

    Use the sharing built into Parallels, or set-up SMB or NFS as entailed above (well, it points at google, but that is the 'answer database' anyways).
  4. itsdapead


    Last I looked, Parallels didn't support "shared folders" under Linux (not a big deal, with so many alternatives).

    You are quite right - SMB or NFS are better long-term solutions. However, in some cases, SFTP gets the job done and can be less hassle to set up. (Having raved about MacFusion I'm going to have to edit in a caveat, though).
  5. Eru Ithildur

    Eru Ithildur

    Oh, dur. My bad... Sorry, I open all the new threads up in tabs progmatically and then just go across reading them, I should have looked which forum I was in before making myself sound like a dummy.

    Everyone else, ignore reference to Parallels shared folders.
  6. ebudan


    Access from Host to SMB on VM?

    (Running Parallels 3.0 B5160 on OS X, Ubuntu Desktop 7.04, nw in shared networking mode.)

    I've managed to get VM->Host access working over sshfs (see However, since the virtual machine is the expendable one, and since ssh is slow overkill for this case, what I'd really like to do is access the VM fs from the Host over SMB.

    Is it possible to access the VM from the Host at all in shared networking mode?
    I've set up an SMB server on the VM, and I'm fairly certain there are no firewalls preventing access on either OS, but no IP traffic is getting through from the Host to the VM.

    Network settings are the shared default: the Host sets up IF en3 with IP, and the VM is NATted to The VM can actually see the host with the actual Host IP, but the host can't get any traffic through to

    Should Host->VM access be possible in shared networking mode? Is this just a missing routing entry on the OS X side? Or is there something more complicated going on?
    (Changing the networking mode to Bridged Ethernet allows the VM and Host to see each other, but then VM->external nw traffic doesn't work, and I'd need to trouble shoot that, instead.)

  7. itsdapead


    Should work - and there can't be much wrong if you've had sftp working.

    I take it you have tried "ping"-ing the VM from the Mac terminal before trying to do complicated things like getting SMB going...?

    What are the IP addresses, router addresses and subnet mask settings for the other network interfaces on your Mac...?
  8. ebudan


    Yup, have pinged, no response. That's why I suspect some kind of routing problem.
    Well, that, and mtr's output:
    > mtr
                                                                                        Packets               Pings
    Hostname                                                                         %Loss  Rcv  Snt  Last Best  Avg  Worst
    You've got a broken (FreeBSD?) system
    Here's relevant bits from ifconfig and netstat on the VM's side:
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface   U         0 0          0 eth0     U         0 0          0 eth0         UG        0 0          0 eth0
    eth0      Link encap:Ethernet  HWaddr 00:1C:42:36:8E:A6  
              inet addr:  Bcast:  Mask:
              inet6 addr: fe80::21c:42ff:fe36:8ea6/64 Scope:Link

    ...and the same on the OS X host. Um, this is a bit longer - it's giving me some unfamiliar BSD interfaces and routing...
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
            inet6 ::1 prefixlen 128 
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
            inet netmask 0xff000000 
    gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
    stf0: flags=0<> mtu 1280
            ether 00:16:cb:8e:e8:2d 
            media: autoselect status: inactive
            supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 10baseT/UTP <full-duplex,flow-control> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 100baseTX <full-duplex,flow-control> 1000baseT <full-duplex> 1000baseT <full-duplex,hw-loopback> 1000baseT <full-duplex,flow-control> none
            inet6 fe80::216:cbff:feb6:94b5%en1 prefixlen 64 scopeid 0x5 
            inet netmask 0xffffff00 broadcast
            ether 00:16:cb:b6:94:b5 
            media: autoselect status: active
            supported media: autoselect
    wlt1: flags=41<UP,RUNNING> mtu 1500
    fw0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 494
            lladdr 00:16:cb:ff:fe:64:eb:78 
            media: autoselect <full-duplex> status: inactive
            supported media: autoselect <full-duplex>
            inet6 fe80::21c:42ff:fe00:0%en2 prefixlen 64 scopeid 0x8 
            inet netmask 0xffffff00 broadcast
            ether 00:1c:42:00:00:00 
            media: autoselect status: active
            supported media: autoselect
            inet6 fe80::21c:42ff:fe00:1%en3 prefixlen 64 scopeid 0x9 
            inet netmask 0xffffff00 broadcast
            ether 00:1c:42:00:00:01 
            media: autoselect status: active
            supported media: autoselect

    Routing tables
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default        UGSc       79      287    en1
    10.37.129/24       link#8             UCS         0        0    en2          UHS         0      166    lo0
    10.211.55/24       link#9             UCS         0        0    en3          UHS         0      114    lo0
    127                UCS         0        0    lo0          UH         20  1729407    lo0
    169.254            link#5             UCS         0        0    en1
    192.168.1          link#5             UCS         1        0    en1          UHS         1       22    lo0      0:4:ed:23:fc:81    UHLW       73       43    en1   1138
    Destination                             Gateway                         Flags      Netif Expire
    ::1                                     ::1                             UH          lo0
    fe80::%lo0/64                           fe80::1%lo0                     Uc          lo0
    fe80::1%lo0                             link#1                          UHL         lo0
    fe80::%en1/64                           link#5                          UC          en1
    fe80::216:cbff:feb6:94b5%en1            0:16:cb:b6:94:b5                UHL         lo0
    fe80::%en2/64                           link#8                          UC          en2
    fe80::21c:42ff:fe00:0%en2               0:1c:42:0:0:0                   UHL         lo0
    fe80::%en3/64                           link#9                          UC          en3
    fe80::21c:42ff:fe00:1%en3               0:1c:42:0:0:1                   UHL         lo0
    ff01::/32                               ::1                             U           lo0
    ff02::/32                               ::1                             UC          lo0
    ff02::/32                               link#5                          UC          en1
    ff02::/32                               link#8                          UC          en2
    ff02::/32                               link#9                          UC          en3
  9. ebudan



    Ahem. Yes, this was a routing issue: the Cisco VPN I forgot to mention happily grabs 10.* to itself. This would probably be evident in the netstat output above for someone more versed in routing tables.

    The obvious solution is to move my Parallels NATted range from 10.211.55.* to some 192.168.* range unbothered by the VPN.

  10. ccparallels



    Can somebody detail how to do the mount itself?

Share This Page