Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

On a workstation we have 32-bit Windows XP hosting 64-bit Windows 7 in VMware Player v5.0.1. We want to directly share a file-system folder between Windows 7 and Windows XP. Directly means that we do not want to go via a network share.

The reason for this is that we are running 64 bit Adobe Lightroom that in Windows 7 which shows the warning: ‘Lightroom Catalogs can not be opened on network volumes, removable storage, or read only volumes’.

Putting every thing into the VM and working the other way around is not very practical because of the amount of data (several GBs) and because of the fact that the data needs to be available even if the VM is not running.

Any ideas how to resolve this?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

There is a trick to do this in VMWare Workstation, but I don't know for sure of Player can do it too... (If not see below for the other variant.)

You create a separate disk-partition on the host specifically for these files. Format this as usual as NTFS, etc, but after you have setup the partition go to DiskAdministrator on the host en remove the drive-letter.

Then map this partition directly on the VM.
On the VM share this partition so the host can access it via the share.
You need to take this roundabout route because you can't have concurrent access by host and VM on the partition itself.

That should solve your problem.

If you don't want to muck around with partitions or are not able to re-partition the host system there is another method as well (and this will certainly work on Player even if the above isn't possible):
On the host install iSCSI target software and expose a large file through that as virtual disk. On the VM use the build-in iSCSI connector. Windows threats iSCSI drives as LOCAL drives so Adobe should be happy with that.
Apply the same sharing method to give the host access to the content of the iSCSI disk.

share|improve this answer
I'm willing to be corrected, but I'd say the second option stands a high chance of data corruption. Windows doesn't support two connections to a LUN / Block Level file system (Which is basically what you're emulating) on anything other than clustered servers. –  Dan Dec 22 '12 at 16:42
(I'm not even sure if it's possible to present an iSCSI target on a client OS, for that matter) –  Dan Dec 22 '12 at 16:47
@Dan The whole point is that you don't access it by both machines. Just the VM which then shares it as a regular network share to the host. I mentioned this already in my answer. As for your second point: Why wouldn't it ? It won't work with a NATted LAN connection on the VM, but in bridge or using an additional host-only connection between VM and host it is no different then any other iSCSI setup. –  Tonny Dec 22 '12 at 22:08
I follow you now ref the sharing, but the OP states that this is impractical so I thought you meant connect using iSCSI on both machines. As for the second, I just meant I don't think XP has any ability to present an iSCSI target without some clunky 3rd party solution. No issue with your answer, though, by the way. –  Dan Dec 22 '12 at 23:58
@Dan Kernsafe is quite good and free. SourceForge has an OpenSource project that is quite basic, but works well for something like this. You don't need all the bells and whistles. (Starwind and the Microsoft free target require W2K8 so they are not much help in this case.) –  Tonny Dec 23 '12 at 9:40

Yes you can share anything and you can access your shared data same as we access in LAN network by using LAN segment in LAN adapter of vmplayer's virtual machine.By using LAN segment between virtual machine the will connect as real LAN.

share|improve this answer
Doesn't answer the question AT ALL. –  Tonny Dec 22 '12 at 13:12

Your Answer


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.