Are you sure that the user making the request is a legal user on the server machine? If not, it's ID will be translated to -2. Perhaps this is an "operator has failed to configure NIS correctly" error?
If so, the workaround is probably to specify both -mapall and -alldirs in the exports file (man 5 exports). On the IRIX box, have you applied Patch SG0003771 or one of the other "libc rollup" patches? IRIX getcwd() is known to use stat64() instead of lstat64() prior to this patch; are you sure you are not using symbolic links, and expecting them to work over NFS? I expect this is related to "Bug 439774: getcwd() doesn't give correct path for some autofs mounted files". There's also a limit on the number of groups that are sent over the wire with an NFS request. Don't expect that putting a user in a group on the NFS server will do anything at all about the group membership testing for the same user coming from an NFS client, and don't expect that more than a small number of group memberships (e.g. the first 6) will be looked at by the NFS server. Also, make sure you are using one of the standard shells that comes with IRIX, and not something like "bash", which has a bogus assumption about the inode number returned by getdents matching the inode number returned by "stat"; the "stat" version should be used, since it is local to the machine doing the "stat", whereas the "getdents" value is local to the host machine (POSIX explicitly prohibits using this value, FWIW). Actually, there's a well known root exploit that uses a getcwd() buffer overflow against IRIX, which has been corrected in more recent versions. Perhaps it is this buffer overflow attack against the IRIX client which is failing? 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
