Subordinate reference stuck in new state - Error: "672 - No access"

  • 7003108
  • 27-Apr-2009
  • 05-Aug-2014

Environment

Novell eDirectory 8.8 for NetWare 6.5
Novell eDirectory 8.7 for All Platforms
Novell eDirectory 8.6 for All Platforms
Novell NetWare 5.1 Support Pack 5

Situation

Some hardware was replaced after a hardware failure.
A partition was removed from a server that had inconsistent passwords for users
A load DSREPAIR.NLM | Advanced Operations | Replica and Partition Operations | Select Replica | Destroy selected replica operation was performed
A server was removed from the replica ring using Load DSREPAIR.NLM | Advanced Operations | Replica and Partition Operations | View Replica Ring | Select server 
Subordinate reference stuck in new state - Error: "672 - No access"
Using DSREPAIR.NLM | Advanced Option | Replica and Partition Operations | Report Synchronization servers report Error: "761 - Have seen state"
Replica Synchronization for a particular partition is halted on - 158 errors.
Using DSTRACE.NLM Error: "605 - No such Partition"
Users can not login.

Resolution

Resolve communication problems and get synchronization going again first.  Without good communications other steps taken to fix replicas stuck in a new state may make matters worse.  If the server is the only one in a new state run another Destroy Selected Replica using the "-A -DR" switch.  This will add it back to the master's replica ring.  If this does not work, try either adding a R/W replica or remove the parent partition.  If all else fails you can run a DSREPAIR.NLM -XK2 | repair local database to remove all replicas from server.  See TID 7001592 for instructions 

If the target server reports Error: "654" after receiving a replica and the replica is in a ON state, you may have to perform a DSREPAIR -XK3 operation on that server.  KB 7015477 has these instructions.

Additional Information

The problem began with the hardware failure.  After the hardware was replaced and the server brought back online, synchronization stopped from that server.

If user passwords are sometimes not working after being changed, this indicates replica inconsistency.  The source of replica inconsistency usually points to a lack of communication and synchronization among the servers in a replica ring.  This should be resolved before attempting any other partition operations.
A Destroy Selected Replica operation should never be performed unless DSREPAIR.NLM has been loaded with the " -A -DR" switch.  Otherwise the master of that partition will not be notified that this server has now become a subordinate reference in the ring.  Afterward you should not remove this server manually using DSREPAIR.NLM from the master's replica ring as this will occur automatically when it is determined that the server does not require one..
Formerly known as TID# 10083374