Thank you to all who replied. I am, you probably guessed, a bit of a RH virgin and didn't know about the heavy patching applied to kernels -- I'm from the Debian world where a range of kernels is always available and trying them out is just an apt-get away. Please excuse my faux pas. Following your advice I've searched around the RH site and found the most recent kernels I could, I've tested 2.6.18-181.el5 2.6.18-175.el5.jtltest.96 2.6.18-164.6.1.el5 2.6.18-128.7.1.el5 2.6.18-53.1.4.el5 behavior is identical for all of them: /home is nfs4 automounted, authentication is kerberos over LDAP. > ls -l /home drwx------ 2 user1 user1 72 Dec 16 16:51 user1 drwxrwx--- 2 user2 userall 72 Dec 16 16:51 user2 > ls -l /home/user2 rw-rw---- user2 userall 0 Dec 17 11:33 group-writable login as user1 > groups user1 userall > pwd /home/user1 > echo "time to die" > ../user2/group-writable -> kernel panic gss_wrap_req [auth_rpcgss] cache_alloc_refill gss_wrap_req [auth_rpcgss] nfs4_xdr_enc_write [nfs] rpcauth_wrap_req [sunrpc] nfs4_xdr_enc_write [nfs] call_transmit [sunrpc] __rpc_execute [sunrpc] nfs_execute_write [nfs] nfs_flush_one [nfs] nfs_flush_list [nfs] nfs_flush_one [nfs] nfs_sync_inode_wait [nfs] nfs_do_fsync [nfs] nfs_file_flush [nfs] filp_close sys_dup2 syscal_call EIP kunmap_atomic kernel panic -- not syncing: Fatal exception Bizzarely, puting the killer command into a script (just to save time) means no kernel panic, I ran the script many times. Garrett Holmstrom: > The right way to fix this problem would be to file a bug against the > kernel package so upstream can backport a fix. They add bugfixes > and new features by patching the same kernel version so the release > can keep the same version throughout its lifetime while still remaining > useful. I'll do that, but do you mean the kernel devs at kernel.org or RH or SL? Cheers, and thanks again for all the help Jim