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

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

Reply via email to