Fix NS_I_DISK_REBUILD_ABORTED 0X400D0058

Quick answer for advanced users

Check the Content Server's server.log for the real error preceding the abort — the code is informational; the root cause is usually a disk I/O error, disk space shortage, or a stalled rebuild. Fix the underlying condition, then restart the rebuild with dscconv or the Admin Console.

What's actually happening here is that 0X400D0058 isn't a fatal error by itself. Content Server raises it when it decides a rebuild can't continue and gives up cleanly. The message includes %1 (%2) — those placeholders get filled with the disk ID and the physical path. The server logs this event at the same time, but the drive's health or the filesystem state is the real story. You've probably seen this after a power outage, a failed disk controller, or when someone accidentally filled the partition to 99% while a rebuild was running.

The reason a rebuild aborts instead of just pausing is that Content Server's rebuild logic is all-or-nothing. It copies data from the source files to a new disk block by block, and any read error or write failure makes it roll back. It won't retry indefinitely because that could mask a failing disk. So the fix is to find out which condition tripped it.

Step-by-step fix

Read the server log. Open the log file (default %OSP_DATA%\logs\server.log on Windows, /var/opt/osp/logs/server.log on Linux). Search for 0X400D0058 and look at 20–30 lines before it. You're hunting for ERR_ or WARN_ entries that mention disk I/O, EACCES, ENOSPC, or EIO. That's your clue.
Check disk space. The rebuild target partition needs headroom — Content Server requires at least 10% free space. Run df -h (Linux) or open Explorer and check properties (Windows). If it's under 10%, delete temp files or move data off.
Verify the source disk is readable. Rebuilds read from the source disk. If that drive is failing, you'll see read timeouts in the log. Run smartctl -a /dev/sdX (Linux) or wmic diskdrive get status (Windows). A status other than OK means the disk is dying — replace it before rebuilding.
Clear the rebuild lock. The abort sometimes leaves a lock file. Stop Content Server (e.g., service ospserver stop), delete the rebuild.lock file in the disk's data directory, then start the server again.
Restart the rebuild. Use the Admin Console: go to Disk Management, select the failed disk, and click Start Rebuild. Or use the command line: dscconv -d <disk_id> on Windows or dscconv -d <disk_id> on Linux (same syntax). Watch the log to see it progress.

If the main fix doesn't work

Run a filesystem check. A corrupt file system can cause spurious I/O errors. On Windows, run chkdsk /f on the affected drive. On Linux, run fsck -y /dev/sdX (unmount it first). Reboot, then try the rebuild again.
Check disk controller settings. Some RAID controllers have write-back caching that can cause timeout errors under load. If you're on a RAID, set the controller to write-through and see if that stabilizes things. It's slower but more reliable.
Increase timeout values. In osp.conf, look for DiskTimeout and IOTimeout. Defaults are usually 60 seconds. If your disks are slow (spinning rust, high latency), bump these to 120. This gives the rebuild more slack and avoids false aborts.
Skip the problematic disk. If the disk is past saving, exclude it from the content database and rebuild onto a fresh disk. You lose the data on that disk, but that's better than a hung rebuild.

Prevention tips

Monitor disk space daily. Set an alert when free space drops below 15% on any partition hosting Content Server data.
Run smartd (Linux) or enable SMART monitoring (Windows) so you know about failing disks before they generate I/O errors.
Schedule regular backups of the content database and files. A rebuild is recovery — you don't want to need it often.
After any power outage, do a manual fsck or chkdsk before Content Server starts. This catches filesystem corruption early.

Real scenario: A user on a Dell PowerEdge R740, Windows Server 2019, saw this code after a RAID controller battery died. The rebuild kept aborting because the controller was running in degraded mode. Replacing the battery and letting the controller rebuild its cache cleared it up instantly.

The fix is almost never to ignore the code and retry blindly. That just wastes hours. Always dig into the log first — the answer's there. If the log is clean, the disk is suspect. Replace it, and the rebuild will finish like it's nothing.