I'm running Fusion 5.0.3 on Mountain Lion 10.8.2 on my RMBP. Running VMs from the local SSD (256GB) works, but when I attempt to run VMs (either newly created or ones I copy after OS install) from an external NTFS-formatted USB 3.0 hard drive, OS X crashes and reboots. I enabled writing to NTFS by following these instructions. I'm able to read and write to the external hard drive with no issues, in fact it's significantly faster than other USB 2.0 external hard drives I own. Is anybody else having this issue and know how to fix?
Below is the "problem" that was reported:
Interval Since Last Panic Report: 1750551 sec
Panics Since Last Report: 3
Anonymous UUID: 5A2D1CF8-9021-B27B-10D7-2E043BA8E8AA
Mon Jun 3 10:58:22 2013
panic(cpu 6 caller 0xffffff7f8b3d405d): "fuse4x: mmap being attempted with no region accessibility (flags=0)\n"@/tmp/fuse4x-kext-6INp/kext-fuse4x_0_9_2/fuse_file.h:51
Backtrace (CPU 6), Frame : Return Address
0xffffff80fc933870 : 0xffffff800901d626
0xffffff80fc9338e0 : 0xffffff7f8b3d405d
0xffffff80fc933940 : 0xffffff7f8b3c9f5f
0xffffff80fc933970 : 0xffffff8009110eff
0xffffff80fc9339a0 : 0xffffff80093859c1
0xffffff80fc9339e0 : 0xffffff800905b69d
0xffffff80fc9339f0 : 0xffffff8009066316
0xffffff80fc933ac0 : 0xffffff8009090464
0xffffff80fc933b10 : 0xffffff7f8b3e813d
0xffffff80fc933bd0 : 0xffffff7f8b3e7430
0xffffff80fc933c20 : 0xffffff7f8b3eae15
0xffffff80fc933c50 : 0xffffff7f8b3e5941
0xffffff80fc933d10 : 0xffffff800911f42d
0xffffff80fc933d60 : 0xffffff8009110d94
0xffffff80fc933dd0 : 0xffffff8009107329
0xffffff80fc933e20 : 0xffffff8009349ed3
0xffffff80fc933e50 : 0xffffff80093768c3
0xffffff80fc933f50 : 0xffffff80093e060a
0xffffff80fc933fb0 : 0xffffff80090cdc03
Kernel Extensions in backtrace:
BSD process name corresponding to current thread: vmware-vmx
Mac OS version:
Darwin Kernel Version 12.2.1: Thu Oct 18 12:13:47 PDT 2012; root:xnu-2050.20.9~1/RELEASE_X86_64
Kernel UUID: 3F93B852-872F-3DF0-BCF8-46D48024C422
Kernel slide: 0x0000000008e00000
Kernel text base: 0xffffff8009000000
System model name: MacBookPro10,1 (Mac-C3EC7CD22292981F)
System uptime in nanoseconds: 5424754920747
last loaded kext at 5411571744467: com.vmware.kext.vmioplug.10.1.24 10.1.24 (addr 0xffffff7f8b3f1000, size 32768)
last unloaded kext at 5240506748378: com.apple.driver.AppleFileSystemDriver 3.0.1 (addr 0xffffff7f8b295000, size 8192)
Model: MacBookPro10,1, BootROM MBP101.00EE.B03, 4 processors, Intel Core i7, 2.4 GHz, 8 GB, SMC 2.3f32
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB
Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533642465238432D50422020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54333531533642465238432D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xEF), Broadcom BCM43xx 1.0 (18.104.22.168.14)
Bluetooth: Version 4.1.2f9 11046, 2 service, 18 devices, 1 incoming serial ports
Network Service: Thunderbolt Ethernet, Ethernet, en3
PCI Card: Apple 57762-A0, sppci_ethernet, Thunderbolt@10,0,0
Serial ATA Device: APPLE SSD SD256E, 251 GB
USB Device: USB 3.0 SATA Bridge, 0x2109 (VIA Labs, Inc.), 0x0700, 0x14a00000 / 2
USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1a100000 / 2
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8510, 0x1a110000 / 3
USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1d100000 / 2
USB Device: hub_device, 0x0424 (SMSC), 0x2512, 0x1d180000 / 3
USB Device: BRCM20702 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x1d181000 / 5
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8286, 0x1d181300 / 6
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0262, 0x1d182000 / 4
1) Upgrade to 10.8.3, it had a HUGE number of bugfixes.
2) The issue is highly likely to be the NTFS format on the external drive. OSX doesn't support it, and third-party drives are problematic at best. Reformat the drive as either FAT32 or HPFS+ (Mac format). I'd avoid exFAT at the moment too, as it's more prone to corruption. If you use FAT32, your VM's will need to be split into 2GB chunks.
dlhotka, thanks for the response. I upgraded to 10.8.3 and still get the same error. It does look like it's one of the components I installed to get RW working with NTFS (fuse4x). I guess that I'll use the external drive for VM storage (and only run from the internal HD) for now as I'd prefer to keep the drive formatted NTFS for compatibility.
FAT32 is the most compatible file system out there :-).
But yeah, if you're on 10.8.3, then it definitely looks like it's the NTFS issue. You may experience issues going through the shared folders function too (since that'll trigger the OSX drivers). If you can, just mount it directly in the VM.
As a general rule I normally do not write to NTFS Volumes from OS X on a daily basis however I do on occasion and at times write some individual files that are large, 10 to 50 GB and have yet to have any issues. I normally do not run VM's from the NTFS Volume under OS X although today I played around for a while doing lots of disk activity seeing if it would be problematic and it wasn't.
Now I did not use the same methods you did to enable write support for NTFS under OS X and though I'd share with you what I'm using. On my newest MacBook Pro I installed just two things, OSXFuse 2.5.5 (2.5.6 has been release since I install 2.5.5 however I've not updated it yet) and the commercial version of Tuxera NTFS for Mac 2012.3.6.
As a general rule I normally keep Tuxera NTFS for Mac disabled and enable it on the fly when I need to write to an NTFS Volume as it is something I do more as the exception not necessarily the rule. However since over the last year I've written a couple terabytes of data, especially very large files to NTFS Volumes from OS X and making sure MD5/SHA1/SHA256 checksums match and have yet to have issues and I consider it safer then using ExtFAT for my use.
This is a defect or limitation in fuse4x. Its complaint, "mmap being attempted with no region accessibility", is entirely bogus, since it is specifically permitted to mmap a region with no accessibility. The documentation for mmap(2) even reveals that there is a defined constant, PROT_NONE, that the caller of mmap should use to request that the region be mapped with no accessibility. That's what we are doing when this failure occurs in fuse4x.
I would expect that this failure will occur whenever an attempt is made to power on a VM whose .vmem (the file which backs the virtual machine's RAM) is located on a filesystem provided via a version of fuse4x with this problem.
You may be able to work around the problem by using virtual machine config options to move the .vmem file to another volume which does not need fuse4x. (I don't immediately recall which options... others here might, or I can try to dig them up...)
To really fix this issue, you'll have to find a filesystem driver without this limitation, whether it's a newer version of fuse4x or another filesystem driver altogether.