Absent Member.
Absent Member.
962 views

Trustees not holding

Every couple of days my users start reporting an 8804 error in the login script, not home directory mapped.

I can go to the user workstation and type in the UNC path of the HD and cannot see it. I check the user account in ConsoleOne and the value is correct. NSM says the directory is cataloged and correct. I check the trustee rights in windows explorer (Right-Click select Trustee Rights) and they appear correct. Just for grins I clicked remove and Apply/OK. When I went back in to reassign the rights they had never been removed.

I can run a backfill operation to restore the trustee rights of the objects and it fixes them. Until a couple of days later the same issue reappears.

I checked DSTRACE on the engine and the other event servers and found some -601 and -603 errors but that was really it. There were a few "replica in skulk" errors, but they are not persistent. I removed all of the replicas, let it sit for the weekend and added them back. I am still getting these errors. DS is healthy as near as I can tell. No obituaries that I can find, and everyone is in sync. I'll post this in the eDir forum as well incase this is not the proper venue for this problem.
0 Likes
3 Replies
Absent Member.
Absent Member.

j,
This sounds like an eDirectory issue. I would open a Novell incident to
get the eDirectory issue resolved.

thanks,
NSM Development

jtreadwell wrote:
> Every couple of days my users start reporting an 8804 error in the login
> script, not home directory mapped.
>
> I can go to the user workstation and type in the UNC path of the HD and
> cannot see it. I check the user account in ConsoleOne and the value is
> correct. NSM says the directory is cataloged and correct. I check the
> trustee rights in windows explorer (Right-Click select Trustee Rights)
> and they appear correct. Just for grins I clicked remove and Apply/OK.
> When I went back in to reassign the rights they had never been removed.
>
>
> I can run a backfill operation to restore the trustee rights of the
> objects and it fixes them. Until a couple of days later the same issue
> reappears.
>
> I checked DSTRACE on the engine and the other event servers and found
> some -601 and -603 errors but that was really it. There were a few
> "replica in skulk" errors, but they are not persistent. I removed all
> of the replicas, let it sit for the weekend and added them back. I am
> still getting these errors. DS is healthy as near as I can tell. No
> obituaries that I can find, and everyone is in sync. I'll post this in
> the eDir forum as well incase this is not the proper venue for this
> problem.
>
>

0 Likes
Absent Member.
Absent Member.

0 Likes
Absent Member.
Absent Member.

jtreadwell,
I have read the threads that you posted to the eDirectory group. Many of
the things mentioned make sense. So we need to help you explore the
situation deeper.

You said in one of your posts that after the Backfill that the users
were able to authenticate and get access to there storage and then
later, the rights had disappeared.

Are the rights disappearing on users that had been recently touched by
NSM, or on users that had been stationary for a while?

NSM acts on events as they happen, so when a create user event happens
for instance the user object is checked for an associated policy. If a
policy is associated the Engine performs a Set Policy operation on that
user object, and creates the storage and sets the appropriate rights.
Once the rights are set NSM does not go back to this user for any
reason, except that an event tells it to do so. Like a rename event, or
move event, etc. Otherwise the only reason for NSM to return to work on
a user object if told to do so by a backfill operation.

Can you send an enginems.txt file to storagemanager-at-novell.com on a
day when you have seen this happen? I can then help to "narrow" down the
possibilities.

thanks,
NSM Development

jtreadwell wrote:
> Please look at my thread from the eDir group.
>
> http://tinyurl.com/3x4jp4
>
>

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.