I'm not sure if this is the correct forum for this, so if it's not,
please let me know.

System:
Mixture of OES11 and OES-NW servers. eDir 8.8.5 on OES-NW servers and
eDir 8.8.7.4 on all OES11 servers.

I have two main data storage servers in my network, both which are
running OES-NW (NW65SP8).

One server contains most users' home folders. The other holds all of the
data that is shared between users within the various
departments/programs in our organization.
They are labeled "h-server" and "n-server", respectively. Yes, I know,
clever names.

I have a third server that used to be located at a remote campus. It
holds both home folders and shared data for the users who were located
at that remote site. It has the equally clever name of "j-server".

The problem:
For as long as support for SSH has existed on OES-NW, I've had an odd
problem with "h-server" that manifests itself in two areas:
SSH access to files with Filezilla and AFP access for OSX users.

The symptom: A small number of users cannot directly access their home
folder on "h-server", but have no problem accessing folders on
"n-server" for which they have appropriate permissions.
Originally I thought the problem was limited to accounts that existed
prior to our move to NW6.5 and OES. I've run into the problem with a
newly created user, however.

What makes it even more odd:
Since SSH connections with Filezilla default to the users' home folders
upon connection, I can set filezilla to connect the user to "n-server"
and, upon connection, they are looking at their home folder that resides
on the h-server!

Unfortunately, that doesn't fix the problem for the OSX users.
To this point, my workaround has been to place the home folders of the
affected users on "j-server".

I'm wanting to consolidate things a bit and retire "j-server", but can't
do so until I can solve this issue.

The OpenSSH logs simply list "failed password"

I've tried using the trace monitor to track the issue down.
With the default selections (DS Agent, Initialization, Inbound Synch and
Outbound Synch) in the trace monitor for the servers without issue, I
see the following:

12:09:30 79B9E060 Agent: Calling DSAResolveName conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSAReadAttrDef conn:2 for client
..J-SERVER.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSASearch conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSAResolveName conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSAReadObjectInfo conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSARead conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSAResolveName conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSASearch conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSAResolveName conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.
12:09:30 79B9E060 Agent: Calling DSASearch conn:123 for client
..<clientname>.<OU>.<O>.<TREE>.


With the problem server, I see nothing whatsoever with Filezilla or OSX,
but see a single entry when I log in with a Windows client:

12:26:23 A7EFD2C0 Agent: Calling DSAReadObjectInfo conn:205 for client
..<clientname>.<OU>.<O>.<TREE>.
..

Has anyone else had a similar issue and, if so, was a solution found?

Since it only happens with a small number of users and only the one
server, I can't help but think it's somehow tied to that particular
server's R/W partition.


--
gathagan
------------------------------------------------------------------------
gathagan's Profile: https://forums.netiq.com/member.php?userid=2788
View this thread: https://forums.netiq.com/showthread.php?t=48989