site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com I realized I didn't say anything useful the last time, so I thought I'd post again with what I observed related to this error. All this assumes that the user with uid==502 is logged in and has a valid TGT in the credentials cache: - upcalls with uid==0 would fail. This makes sense, but since I needed system Ops related to NFSv4 such as Renew to work, I mapped uid 0 to the uid of the user that did the mount (ie 502 in this case). --> when uid 0 was replaced with 502 in the upcall, it worked fine. - I still saw some of these errors for uid == -2. (I presume that some daemon is poking at the file system, but haven't yet tracked that out. Someone was nice enough to email me a dtrace script to do this, but I haven't gotten around to using it yet.) To see if it was caused by the wrong uid, I tried mapping the uid of -2 to 502, like I had done for the system Ops. (Wouldn't make sense to do this for production code, it was just an experiment.) --> Still failed with the error, even though the upcall had the "correct" uid as argument. So, it seems that some processes/threads can't authenticate even if the uid is correct. I suspect it has something to do with accessing the credentials cache (which I understand lives in VM on Leopard). When it comes to control of access to a VM object on the Mach side of things, I know diddly about it, so this is just a wild guess. Hopefully this might be of some use? rick _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com