NFS write access crashes Mac host

[partly SOLVED] NFS write access crashes Mac host

I've got a quite peculiar problem here ... I have a Gentoo Linux install in a VM in Parallels Build 5160. The host machine is a MacBook with OS X 10.5.1. I've shared my home dir between the installations: it's exported with NFS from the Mac, and the Linux VM mounts it.
Since I've got Leopard installed, any write access over NFS (from the Linux VM to my home dir) crashes the Mac. The Mac freezes and I get the "You must restart your computer now" message.
When I ran the exact same installation on my old MacBook with OS X 10.4 installed, I never had this kind of problem at all. I've seen this with a Ubuntu install inside a VM on a Mac Pro with OS X 10.4, though, and I wasn't able to resolve this as well.
Hints are extremely welcome, as I develop PHP stuff within the VM which occasionally writes stuff to the shared directory.

 

It only just occurred to me that there's a new Parallels build available since yesterday. I just installed it, and now the problem is gone. Phew!

 

BTW, this still occasionally happens to me, but it's at least not all the time any more. Annoying nonetheless. Am I the only one who experiences this?

 

Hello,

could you please provide me with crash logs from /Library/Logs?

Best regards,
Stacey

 

Sure, here is the latest one from a week ago:

Code:

Thu Jan 24 13:17:36 2008
panic(cpu 1 caller 0x001A7BED): Kernel trap at 0x002be827, type 14=page fault, registers:
CR0: 0x8001003b, CR2: 0x311bf806, CR3: 0x010f2000, CR4: 0x00002660
EAX: 0x311bf80a, EBX: 0x00000000, ECX: 0x25a9fffa, EDX: 0x311bf806
CR2: 0x311bf806, EBP: 0x679efe68, ESI: 0x0b0e2e14, EDI: 0x00000009
EFL: 0x00010246, EIP: 0x002be827, CS:  0x00000008, DS:  0x0ce10010
Error code: 0x00000000

Backtrace, Format - Frame : Return Address (4 potential args on stack) 
0x679ef3f8 : 0x12b0e1 (0x455670 0x679ef42c 0x133238 0x0) 
0x679ef448 : 0x1a7bed (0x45ea20 0x2be827 0xe 0x45e1d4) 
0x679ef528 : 0x19e517 (0x679ef540 0x44 0x679efe68 0x2be827) 
0x679ef538 : 0x2be827 (0xe 0x6980048 0x1ca0010 0x1000010) 
0x679efe68 : 0x2d4dcf (0xb0e2de8 0x7989904 0x679efedc 0x679eff4c) 
0x679eff78 : 0x3da847 (0x69d0e10 0x700ed40 0x700ed84 0xffffffff) 
0x679effc8 : 0x19ea34 (0x6ed34c0 0x0 0x1a10b5 0x6ed34c0) 
No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0xb040ef78

BSD process name corresponding to current thread: nfsd

Mac OS version:
9B18

Kernel version:
Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386
System model name: MacBook3,1 (Mac-F22788C8)

I'm not sure whether I already had the very latest version of Parallels that came out a few days ago installed when the crash happened. What I did was just typing

Code:

less <some file in the NFS shared directory>

into a terminal window with an ssh session to the VM, then immediately after hitting enter the "You have to restart your computer" screen appeared. I don't know whether it's relevant, but the VM doesn't have X11 installed, so I basically only access it via SSH and HTTP.

 

I am getting the same problem - in addition, I'm getting some corruption of file permissions. I have a host directory mounted by a debian etch guest in parallels, used for sharing my source code tree for development work (editing on os x, running on debian).

I have previously used nfs manager to setup the nfs mounts, so the /etc/exports file had a line:

/Users/darius/workspace -alldirs -32bitclients -mapall=darius -network=10.211.55.0 -mask=255.255.255.0

I've manually changed this to be:

/Users/darius/workspace -mapall=darius -network=10.211.55.0 -mask=255.255.255.0

and will be trying again to see if it works any better.

 

Hello,

could you please tell me more information about the NFS?

Best regards,
Stacey

 

Hi Stacey, thanks for getting back to us, hi Silarsis, thanks for letting me know that I'm not alone

On the Mac, /etc/exports looks like quite plain & simple:

Code:

/Users/kiezpro    -maproot=root   10.211.55.3

In the Linux VM, I automatically mount the NFS share in /etc/fstab like this:

Code:

10.211.55.2:/Users/kiezpro	/home/kiezpro	nfs	defaults	0 0

That's basically all there is to it. The Linux VM is running Kernel 2.6.23-gentoo-r3 - to be honest, I have no idea whether the Gentoo patches do anything to the NFS functionality. I've had another crash yesterday, which was the first since 2008-01-24. It shows basically the same information in the Panic Log as last time, so I didn't bother posting it here.
BTW, I also get the occasional permissions screwup when an application creates a directory on the NFS share, then the permissions are set to 0000 instead of the usual 0755. I couldn't make out a pattern in this behaviour, it just happens once in a couple of times. To me it seems like this only happens for directories, not for files, but I'm not absolutely sure. It's kind of annoying for developing applications that create a lot of caching directories, but then it's easy to work around it by putting the cache directory to some place within the VM. This might be a bug in Apple's NFS server though, I didn't really have the time to test it with a "real" linux box as a client yet.
If you need more information, I'll be glad to supply it!
Cheers,
Kiezpro

 

Your description of the permissions behaviour matches mine exactly - mostly/all directories (in my case, .svn directories more often than not), permissions sometimes set to 0000.

Linux side fstab entry for me is:

icanhas:/Users/darius/workspace /home/jet/mnt nfs user,auto,exec,vers=3 0 0

I actually have two parallels instances running usually (well, three, but two that nfs mount) - one debian sarge, one debian etch. I haven't noticed whether etch or sarge shows different behaviour - as far as I can tell, they both misbehave.

What other information would you like?