Joined: Fri Dec 05, 2008 03:42
Posts: 1

NTFS-3G, Bootcamp, and Parallels

Hi, I apologize if this topic has been covered somewhere already, I did a few searches and I didn't see anything like it.
I recently got a macbook pro and when I heard about ntfs-3g I was pretty excited.
From what I read and understood, ntfs-3g would allow parallels to access a boot camp partition that was formatted in ntfs and use it as a virtual machine inside windows.
I attepted this, and it all seems fine and dandy ant first, but my windows partition keeps on corrupting making it impossible to boot into windowws through bootcamp or parallels.
I am not sure if it is the ntfs driver, but i cannot see what else could be causing the problem. I am very careful to always shutdown the computer through the start menu in both boot camp and parallels so that data isnt corrupted, but it keeps happenning anyways.
Am I missing something? Is it just a flaw in parrallels/ntfs-3g? Am I doing something wrong? Any help would be appreciated.

Joined: Sat Oct 06, 2007 09:24
Posts: 530

There are a few misconceptions here:
1. Parallels does not need NTFS-3G to be installed in order to be able to boot off Boot Camp partitions. (I'm not sure if Parallels are using NTFS-3G or some derivate internally to do certain operations, but as a user, you should not need to worry about it..)
2. NTFS-3G is used to read your NTFS partition from inside Mac OS X, without any virtual machine.
So NTFS-3G has nothing to do with Parallels or virtual machines in general.
If you get a corrupted Windows partition from using Parallels, that's an issue you should be discussing in a Parallels forum. If you get a corrupted Windows partition from accessing your Windows partition with NTFS-3G, that's an issue you should be discussing here.
If you somehow manage to have the NTFS partition mounted with NTFS-3G at the same time as the Windows virtual machine is using it, then data corruption is not only likely to occur, it will occur. If that is the case, you have encountered a bug in Parallels.

I have come across this very problem a few weeks ago and stopped using the latest parallels as a result. It is nice to see relevant comments, thanks for sharing.
I discovered NTFS-3g more than a year ago and I have kept it updated and enjoyed it thoroughly since then. Before the latest major upgrade of parallels (3.5 to 4.0 i believe), My ntfs Bootcamp partition would be automatically dismounted and parallels would automatically mount a shortcut to the parallels enabled partition once windows had started up. Expecting increased reliability with parallels 4.0, I purchased the upgrade and installed. When I started using it, I noticed that the windows partition did not dismount in mac when starting up parallels with it (or would dismount it and automatically mount it again). As far as I can remember, parallels would still generate the shortcut to the partition through parallels, resulting in two links to the partition. Then everything started turning into a great big mess: Every time I restarted the machine, chkdsk would find errors in the mft record, in system files, and apparently in most files that I had accesed. I tried transferring files from mac to windows and vice-versa, and everything would appear fine until I tried to access the files (docs, pics, etc) which turned out to be corrupted. I tried dismounting the partition and the virtual partition on mac, but it still proved unreliable. Since then I have had to reinstall windows, and I haven't had time to address the issue properly, so I have just been booting in either mac or windows.
This is the first forum I visit now that I have started to look at the problem again, so there might already be a solution to the problem on the parallels website, but it seems logical, like unsound says, that the problem is due to a bug that allows simultaneous mounting from ntfs-3g and parallels. I will have a look around and get back to this topic with some links if I find anything. If you've come across anything though, please let me know.

Joined: Tue Nov 21, 2006 23:15
Posts: 1648

Re: NTFS-3G, Bootcamp, and Parallels

We just recently discussed this issue with Parallels and we come to the conclusion that using the latest version of NTFS-3G and Parallels must be safe. Both of us are using locking to prevent concurrent write access.
Thanks, Szaka

Joined: Sat Oct 06, 2007 09:24
Posts: 530

Re: NTFS-3G, Bootcamp, and Parallels

As a matter of fact we have been communicating with Parallels recently about this, and using the latest release of NTFS-3G should make sure that the devices that NTFS-3G currently uses are locked in a way that should prevent Parallels from using them concurrently.
I'm not sure if this applies to the latest released Parallels version, but it should at least apply to the latest NTFS-3G version..
So basically, I'd like some sort of confirmation that when using the latest NTFS-3G version (2009.2.1 Update 1) and the latest version of Parallels (whatever version that is) this situation can still occur. Can you reproduce this problem with the latest releases?
- Erik

Thanks for your input. I tried going back to parallels with the latest NTFS-3g and parallels versions.
Somehow, my windows system files managed to disappear completely off the drive and the parallels upgrade process (adaptation of xp partition for use with parallels) left an enormous and most likely unrecoverable mess in my registry as well. Luckily I had an old backup partition which let me get back to work, so it was a relatively minor setup in the grand scheme of things, but my fresh install with all my programs and everything is no good any more. I'm sorry I didn't get back to you sooner about this but I've been so busy and so pissed off about this that I just left it completely.
I have not yet commented on any of this in the parallels forum, and it seems that it is more relevant there. I just don't know exactly what I'm going to say, because I have wasted weeks of my life to trying to get a stable mac-xp setup with their software.

Unfortunately in combination with Parallels NTFS-3G shows a rather inconvinient behavior compared to OS X inbuild read-only NTFS driver and Paragons NTFS for Mac.
NTFS-3G: NTFS volume remains locked by NTFS-3G (aka remains hidden from Parallels) and cannot be accessed by Parallels without manually disabling NTFS-3G via System Preferences first.
OS X/Paragon: NTFS volumes gets locked by Parallels (aka gets hidden from OS X) as soon as a virtual instance of Windows is started and can be used by Parallels without any manual intervention. As soon as the virtual instance of Windows is shut down the NTFS volume becomes accessible by OS X again.
I obviously prefer the latter behavior and don't like the manual inconvinience presented by NTFS-3G, but others may see it the other way around.

Joined: Sat Oct 06, 2007 09:24
Posts: 530

Re: NTFS-3G, Bootcamp, and Parallels

If the NTFS volume is locked by NTFS-3G, that means NTFS-3G is using the volume.. i.e. the mount is still active. The volume should definitely be locked when NTFS-3G is using it, this is not a bug.
So it seems that Parallels doesn't succeed in unmounting the volume before attempting to use it. This sounds like a Parallels bug, and should be reported to their forums.
I'm using VMware Fusion myself, and there are no such issues there.

Fair enough. Still it's odd that both of the other drivers show no such problems in combination with Parallels. So at least something is different with NTFS-3G that may not all be the fault of Parallels only. ;)

Joined: Sat Oct 06, 2007 09:24
Posts: 530

Re: NTFS-3G, Bootcamp, and Parallels

Yes, the difference is that ntfs-3g acts from user space, meaning it has to use a different method for locking devices (advisory) than those used by kernel drivers like Apple's drivers and Paragon.
Parallels and ntfs-3g use the same locking method (we have discussed this to ensure compatibility). So you should in fact be glad that opening the device fails when it's in use. Otherwise you might get data corruption and general chaos since two applications are then able to read and write to the same device.
So, again.. this should be reported to Parallels.
You should be able to easily work around this bug by just unmounting the affected volume with Disk Utility prior to using it in Parallels.

Ah, so it's a user-space vs kernel-space thing. Again, fair enough. I didn't even consider it a bug, just an 'inconvinience'. But yes, it should be reported to Parallels (if they don't know already yet anyway) so that I can think of a better solution (especially since you said this isn't a problem with VMWare).