Step-By-Step: Handling a corrupt volume object in NDS

by Scott Lowe MCSE | Feb 21, 2003 8:00:00 AM

Tags: Directory services, Scott Lowe MCSE, Novell NDS, volume object, DSRepair

Takeaway: Recover from a corrupt volume object in a NetWare NDS

Data is the lifeblood of most companies today, and access to that data is critically important to their success. When the data is corrupt or another problem prevents access, the result can be lost productivity, lost revenue, and worse if there are no backups.

While NetWare is generally extremely stable and reliable, there are times when it falters. One such time is when an NDS disk volume object becomes corrupt. In this situation, your users may be unable to map drives to the resources and unable to access the resources via UNC paths—or the data could simply be gone. Here’s how volumes in NDS become corrupt and what you can do to repair them if corruption occurs.

How does it happen?
In NetWare, volumes on servers are represented as objects and managed in NDS. As with any database, corruption can occur in NDS, which is why it's necessary to run DSRepair occasionally. At other times, data can appear to be corrupt when it isn't. For example, in some instances an NDS volume object can be corrupted when running the Novell Migration Wizard to do an across-the-wire upgrade to NetWare 6. During this process, a new Entry ID (EID)—which does not match the EID on the volume itself—is assigned to the NDS volume object that's being migrated. As a result, the object in NDS is no longer accessible, users are unable to map drives, and a DSRepair returns error 608. The tips in this article should help to correct this problem.

Changing a server’s name also has the potential to create a problem addressing the NDS objects related to its volumes. These instructions will help if you've encountered this problem, as well.

Fixing a corrupt volume object
There are a number of ways to attempt to repair corrupt volume objects. The first thing you should try is a simple DSRepair or VRepair. If one of those utilities can fix the problem, you’re generally in good shape, as trustees should be maintained.

A slightly less comfortable solution
Whenever possible, I would personally prefer to use DSRepair or VRepair to fix volume objects. There are times, though, when this doesn’t do the trick and more potentially perilous steps need to be taken. One of these perilous steps involves deleting the volume object in question. I’ll be the first to admit that I don’t enjoy deleting objects that represent the data in my organization—even with good backups.

If you do get to a point where you realize that this radical step is necessary, there are some steps you should take to make sure that access to the data is restored in the best condition possible.

My installation
For this example, I'll use a NetWare 6 server with two volumes named SYS and VOL1, and ConsoleOne for administration. My NDS tree name is NDS-LAB, and the server is named nw6-old.lab1.nds-lab. My examples will be presented as though the NDS volume object for VOL1 has become corrupt.

After running an unsuccessful DSRepair, you need to delete the object that represents the volume object in NDS. In ConsoleOne, right-click the volume object and choose Delete NDS Object from the shortcut menu, as shown in Figure A.

Figure A

Here's where you delete a volume object in NDS.

Next, you need to do one of two things. The first—and more preferable option—is to type load DSRepair from the server prompt. Choose Advanced Options | Check Volume Objects And Trustees. This will recreate the NDS volume object (which it did for me in my lab, as shown in Figure B). This option stands the best chance of retaining the trustee information related to the deleted volume.

Figure B

The NDS object representing my volume has been recreated.

If the DSRepair doesn’t work and the volume object still isn't in NDS, you then can run NWConfig and choose Directory Options | Upgrade Mounted Volumes Into The Directory, assuming that the volume in question is actually mounted. This procedure will scan the server for mounted volumes for which there is no corresponding NDS object. Then you'll be prompted to add these volumes, as shown in Figure C. Note that using this method will result in a loss of trustee information for the affected volume.

Figure C

NWconfig will ask if a related object should be added to NDS.

In either scenario, the outcome should be a new NDS volume object pointed at the affected volume, as shown in Figure D.

Figure D

My example volume object has been restored.

After the creation
Unfortunately, deleting volume objects can have adverse consequences that may not be fixed by simply recreating the volume. For example, you may have to re-home a user’s home directory on his or her profile tab. When a volume object containing home directories is deleted, the pointers to these directories can also be lost. In addition, print queues on the deleted volume are corrupted, and there can be problems with any NDPS Print Managers that use the volume in question. Before deleting the volume, it's important to point the Print Manager somewhere else. Additionally, if you used the NWConfig method to recreate the volume object, trustee assignments will be lost and will need to be restored from a backup.

1 comment(s)