Sharing a 'home' directory between Windows/Mac

Hi. Wanted to post this article about how to make your Mac 'Home' folder equate to your Windows 'My Docs' folder...

It works pretty well for me, the only problem is going from work to home when my IP changes, I have to remap my drive.

The article: http://techpedia.org/a/28

 

This is very cool, thanks! I will have to give this a shot.

 

Use Bonjour instead

Very nicely done instructions. However, maybe you should consider revising the text accoding to information in this thread:
http://forum.parallels.com/thread2864.html

Local names w. Bonjour is the easiest way to share files. And no IP remapping.

 

I think this is a very bad idea !

Surely, one of the reasons for using a Mac is it's excellent security in comparison to Windows, which has non-existent security.

Making your files common in the suggested way, means you have just made your Mac as unsecure as a PC !

 

That's why .local names would be better, right?

 

My approach is to disable sharing on the Mac side completely.

On the Windows side, the 'My Documents' folder is shared, so that the Mac can read and write to it as a network drive in the usual way.

I don't keep any critical files in the Windows installation, and indeed, I don't connect to the Web within Windows, unless I absolutely have to (and then only using Firefox). I regard the Windows installation as a necessary evil, but treat it as disposable.

 

Changed it to use the Bonjour method. I didn't even think of that...thanks.

So far as security: the assumption is that you are using Windows properly, meaning patched and secured. I guess this tip is oriented more toward those who haev their Windows installations under control...

 

To be honest, keeping Windows patched and secured is not enough. Nor for that matter is having a decent firewall and/or antivirus system on board. Windows is just too insecure. Furthermore, using Windows File Sharing opens a vulnerability on Mac OSX as well---for example, SMB passwords are less secure than Mac OSX passwords.

However, there are three ways to satisfy the security concerns.

1) Alter the configuration of the SMB daemon so that it only serves files over EN2, the Parallels Host-Guest adapter if you are using host-only networking.

2) Configure the firewall so that it blocks all SMB traffic to/from the internet, except for the IP address of your Parallels guest. If you're using host-only networking you can open SMB to just EN2 instead of going by IP address.

3) Use Parallels Shared Folders instead of SMB.

 

Those are great points. I'll (unless someone else wants to) write that up and add it.

 

Just because Windows defaults to being insecure doesn't mean that it can't be used securely.

Summary statement for how to avoid the vast majority of Windows XP SP2 problems:

1) Don't use Internet Explorer

2) Don't use Outlook / Outlook Express

3) Do keep up with Windows Update

4) Do use antivirus (or don't download files from unreliable sources) and do use a firewall (preferably all the computers ought to be behind a real hardware firewall which blocks everything incoming)

In fact I've run Windows XP for years without any sort of spyware or virus concerns by doing #1-3 behind a regular firewall. It's the sort of "high risk" behaviors that get people into trouble. Quite frankly most of the problems I've seen come from people installing something themselves that they shouldn't have (which is the one real vulnerability that Mac OS X has, people who are too trusting of stuff that they download and install).

Windows is less secure than OS X, but it can be used, fairly easily, in a secure way.

 

Bonjour addresses safe?

Please correct me if I am wrong, but if you use Bonjour local names (not visible "outside"), instead of IP's, one does not have the security issues raised above? This is important for me to understand as I work in a hospital environment (albeit the mac is on an university network).

 

Luomat, I just don't agree with you (with one caveat, see below).

I'm happy for you that you haven't had any problems, truly. But if you leave your computer on the Internet long enough, you're going to get bit. There are many avenues to hack into Windows, and keeping people off of Internet Explorer and Outlook isn't sufficient. Windows Update is great, but their response time is not adequate. And antivirus software is imperfect and suffers delay issues as well.

I've only been hacked once in the last few years. And it was done by exploiting a newly discovered vulnerability in a piece of mainstream software I was using. My firewall eventually tripped them up, but not before the hackers had successfully installed some sort remote control software. The point was, however, that I follow #1-#4 to the letter---and still got nabbed.

Now, having said all that, you will note that what I recommended was akin to keeping the firewall as closed as possible. Using host-only networking, you can effectively put your WinXP guest behind a NAT-style firewall. And by configuring smb.conf properly, you can make sure that outside users on your intranet can't even see that your OSX system is running SMB.

 

By the way, if you're running host-only networking, and your Parallels host-guest adapter is "en2", then the following two lines added to the "global" section of your /etc/smb.conf file should make sure that your SMB service is seen only by your Parallels guest and not by the outside world:

bind interfaces only = yes
interfaces = en2

 

I agree with Luomat for several reasons besides the ones he mentioned.
* Windows, with proper security measures, is not a threat to OS X
* Even if a Windows virus is attached to a file (most attach to executables or use Win paths), it can't affect the OS X side
* Many networking solutions that require a loopback connection from Win to OS X and back will not work the way you suggest
* Host only transport is much slower than the SMB share currently
* Sometimes you must use Windows to access internet based resources (some sites require IE for example)
* Certain windows applications require internet access (Windows itself for example)

The NAT approach you describe does not work (for me anyway). It effectively disconnects Windows from the network (in bound traffic packages). Perhaps I misinterpretted your instructions but this seems like a severe measure that is not necessary IMO.

 

Yes, I think that's fair---except for the fact that SMB file sharing on Mac OSX uses a password system that is less secure than Mac native passwords. But in general, yes, I did not mean to suggest that a WinXP VM could somehow end up corrupting your Mac OSX host. I just mean that your VM could get hacked just like any other Windows machine

I'm not sure I understand this. I have SMB service running between Mac OSX and the WinXP guest right now. It works perfectly. Furthermore, SMB is being served only through the Parallels host-only network so it's secure from outside attack.

Agreed. But I think you might be confusing terminology here. When I say host only I am talking about the network connection, not the file service. Parallels Shared Folders or (PSF) is the proper name for Parallel's file service. I do agree, though, that currently PSF is buggy and slow and SMB works better. I have disabled PSF altogether and am running SMB right now.

Nothing I am suggesting prevents that. I have a totally secure SMB connection between MacOSX and WinXP right now, and my WinXP guest is free to surf the Internet and connect to other SMB shares. Perhaps I wasn't clear, but my solution is very specific and minimal---it's objective is simply to prevent Mac OSX's SMB service from being visible to the Internet while it is serving your Parallels guests. That's it.

Ah, OK, I think I see your point. If you need inbound access to your Windows guest, then using a host-only network by itself is not going to work for you. You are right.

However, you can still use the firewall approach I talked about: configure your Mac OSX firewall to serve and respond to SMB/NMB packets only to/from your guest VM's IP address. Outside Internet users should not be able to detect that you are offering SMB service on your Mac at all. And the Windows machine will have the same access it has always had.

Ideally, it would be great if Parallels would allow you to create two network adapters on your guest VM: one host-only networking adapter and one bridged networking adapter. Use the bridged networking adapter to get all of your regular Internet service, and use the host-only network to do host-guest communication. Set up SMB service on MacOSX to serve only that adapter.

Alas, I don't think that's currently possible. It ought to be, though!

 

As many have pointed out about leaving SMB open on the Mac, I've worked the issue some more. There are a number of needs going on here from basic sharing to service exchange between the guest and the host. Rather than flood this forum, I wrote a white paper on one possible solution to a series of particular issues that address the current shortcomings of Parallels:

1) Without a DNS that can register a Mac host name, drive mapping is problematic from the Guest.
2) Host only networking cuts off the guest from the world.
3) Host only networking prevents service interaction between the host and guest.
4) SMB options, using the default firewalls, are either fully open or closed using the standard tools provided in OS X making SMB shares unattractive and a potential security risk.
5) Fixed IPs and other hard coded solutions cannot be used in many cases due to roaming nature of network connections that laptop users often encounter.

The solution I came up with still uses the bridged connection but is somewhat more secure and doesn't require editing any config files. It allows for two way communication between the host and guest without cutting of the guest from the world and without allowing the world into the host or guest. This also allows both Host and Guest VPN connectivity and, short of two adapters from parallels, the best solution for my needs thus far.

You can find the white paper here:
http://www.microdeveloper.com/html/parallels/share_howto/index.html