There are some general rules of thumb for situations where the local ds database won't load. Most of this has already been mentioned. First check that timesync is in place and synchronised to the network (although that of itself shouldn't normally stop ds from loading).

Sometimes a screwy timestamp can be written to a record. DS will report this in its last modified time. If ds detects the current time is earlier than the last modified time it will have a problem with that and switch to synthetic time until it is resolved.

Firstly, check free space on the SYS volume. If you're out of space or you suspect it WAS filled up at some point then I'm afraid it's all over red rover. Skip to the end and clean up. If space is merely low (below 20%) I suggest a cleanup and purge the SYS volume. Your server will thank you for it. If you are using software mirror, this can also be a source of problems. You will need to check free blocks as well. With mirroring, you need at least 10% free blocks. Breaking the mirror can fix ds problems on a server. Problems with SYS volume usually generate a -632 error.

Next step is to down the server, disconnect from the network and restart the server. If it is a ds comms problem then ds will load and you can use dsrepair on the local database using 'dsrepair -a' -> advanced options -> repair local database.

If ds still fails to load type 'm ds*' and check version numbers to make sure you have the same version for all ds modules.

Still problems? Check to see that NICI and SAL are loading. If they aren't try to load them manually. Then 'load ds', you may need to 'set dstrace=*.'

If there are still problems, it's time to get serious. Down the server and start it up with 'server -ndb'. Hopefully this will enable you to run a 'dsrepair -a' without nds loaded. There are also a swag of dangerous switches you can use depending upon the specific error message you receive such as -xk8 or -736. Use these with caution, or simply skip to the next step.

Finally, as long as you have other replicas it shouldn't be a problem to remove the replica off of that server and then later restore it using NDS manager. load the local database using 'load ds -ndb' and then dsrepair -a and repair local database again. If this doesn't work, you'll need to remove ds completely from the server.

'Load nwconfig' and try to remove ds from the server. It will probably fail. Never mind, type 'load ds -ndb' or 'server -ndb' then 'nwconfig -dsremove' then remove nds from the server. You will get errors, but it
WILL work, despite saying that it won't. dsrepair from the master and restart server. Use nwconfig to reinstall NDS. You will lose rights on the volumes, queue based printers, home directory links, directory map objects etc. Rights can be restored with TRESTORE if you have made a habit of using TBACKUP. If not, and you have a Netware 4.11 server in the tree, you can use DSMAINT -PSE to prevent some of the losses.

If things are really bad, you may need to delete the server object from the tree using ndsmgr32.exe before inserting it back into the tree.

If removing DS tells you it's already removed, but installing DS gives the error "Failed to upgrade the Novell eDirectory database. Nwconfig-6-593", see

From the TID : Sounds like there are still some DS files in sys:_netware, such as nds.rfl, nds.db, nds.01, *.nds, etc. If the DS has been removed, these files should no longer exist.
You may want to try to force DS off of the server with 'nwconfig -dsremove'. If that doesn't work, you can try to remove the above files out of sys:_netware manually. Move them to a temporary location and be sure to document their attributes so you can restore them if needed. You can use cpqfm.nlm to get into sys:_netware and do this. It's available from