Can you create an ftp/ ssh tunnel to transfer files between VM and host machine?
- Thread starter mikelley
- Start date
mikelley said:
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://10.211.55.5
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:
Eru Ithildur
Forum Maven
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).
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).
Eru Ithildur said:
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).
Eru Ithildur
Forum Maven
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.
Everyone else, ignore reference to Parallels shared folders.
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 http://ubuntuforums.org/showthread.php?p=1932551). 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 10.211.55.2, and the VM is NATted to 10.211.55.3. The VM can actually see the host with the actual Host IP, but the host can't get any traffic through to 10.211.55.3.
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.)
Thanks,
//e
(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 http://ubuntuforums.org/showthread.php?p=1932551). 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 10.211.55.2, and the VM is NATted to 10.211.55.3. The VM can actually see the host with the actual Host IP, but the host can't get any traffic through to 10.211.55.3.
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.)
Thanks,
//e
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...?
Yup, have pinged, no response. That's why I suspect some kind of routing problem.
Well, that, and mtr's output:
Here's relevant bits from ifconfig and netstat on the VM's side:
----
----
...and the same on the OS X host. Um, this is a bit longer - it's giving me some unfamiliar BSD interfaces and routing...
----
Well, that, and mtr's output:
Code:
> mtr 10.211.55.3
Packets Pings
Hostname %Loss Rcv Snt Last Best Avg Worst
You've got a broken (FreeBSD?) systemHere's relevant bits from ifconfig and netstat on the VM's side:
----
Code:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.211.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 10.211.55.1 0.0.0.0 UG 0 0 0 eth0
Code:
eth0 Link encap:Ethernet HWaddr 00:1C:42:36:8E:A6
inet addr:10.211.55.3 Bcast:10.211.55.255 Mask:255.255.255.0
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...
----
Code:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
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
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1356
inet6 fe80::216:cbff:feb6:94b5%en1 prefixlen 64 scopeid 0x5
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
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>
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::21c:42ff:fe00:0%en2 prefixlen 64 scopeid 0x8
inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255
ether 00:1c:42:00:00:00
media: autoselect status: active
supported media: autoselect
en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::21c:42ff:fe00:1%en3 prefixlen 64 scopeid 0x9
inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255
ether 00:1c:42:00:00:01
media: autoselect status: active
supported media: autoselect
Code:
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.254 UGSc 79 287 en1
10.37.129/24 link#8 UCS 0 0 en2
10.37.129.2 127.0.0.1 UHS 0 166 lo0
10.211.55/24 link#9 UCS 0 0 en3
10.211.55.2 127.0.0.1 UHS 0 114 lo0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 20 1729407 lo0
169.254 link#5 UCS 0 0 en1
192.168.1 link#5 UCS 1 0 en1
192.168.1.2 127.0.0.1 UHS 1 22 lo0
192.168.1.254 0:4:ed:23:fc:81 UHLW 73 43 en1 1138
Internet6:
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 en3Solved
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.
Thanks!
//ebu
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.
Thanks!
//ebu
ccparallels
Member