Pierre Klovsjo writes: > Your answers gives me a few indications on what could be my problem. > I have my home directory [b]NFS:/export/home/expl1/pklovsjo[/b] mounted in > my global and non-global zones (NIS) and i have also some automounts running.
Does the script you're using redirect any I/O to any files that might be in your NFS-mounted home directory? > [b]epsu11un:/opt/SUNWspro[/b] > [b]epsu11un:/export/home/appli1/SVR4/local[/b] What is in that second path? > If NIS is not working in the zones am i then supposed to create usernames > locally ? NIS shouldn't have anything to do with this. It's an NFS (file system) issue, not NIS (name services). The problem isn't that NFS doesn't work, it's that an NFS client operating in one zone cannot be accessed by a process running in another zone. To implement that restriction, the undocumented (private) zone_enter() function used by zlogin checks whether any part of the process address space or any file is open on NFS. If so, then the operation fails. Here's an experiment that might clarify the situation. Stop zlogin at the point of entering the zone, like this: # truss -t\!all -Tzone_enter zlogin test Then dump all of the file descriptors and mapped files: # pfiles `pgrep -x zlogin` # pmap `pgrep -x zlogin` Look through the output for anything that's resident on an NFS file system. (My guess is that the problem is something simple like redirected stdio, but that application directory could also be an issue.) -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
