This guide uses a missing three-disk RAID 5 Btrfs volume2 (/dev/md2) in a ASUSTOR LOCKERSTOR 6 Gen2 with ADM 5, no NVMe cache as an example.
⚠️ Note: To restore the proper volume configuration data, it is advisable to have a backup copy of your /volume0/usr/etc/volume.conf file.
USE AT YOUR OWN RISK
Problem Context
When disk volumes (such as a RAID 5 array) are temporarily removed from an ASUSTOR NAS to utilize the physical drive bays for alternative purposes (e.g., MyArchive drives), the ADM 5 operating system automatically purges the volume registration entry from its internal configuration database.
Upon reinserting the original drives, the NAS kernel may recognize the physical disks, but the ADM storage daemon ignores the array during startup, rendering it completely invisible in both the web interface (Storage Manager) and the system directory tree, despite the metadata and data remaining completely intact.
After conducting some tests and experiencing some failures, I finally performed a successful procedure. I then created a comprehensive summary in the hope that this guide would be useful to others.
I assume that the user has some Linux knowledge, but any doubts should be answered by the current AIs. For free AI, I recommend using Gemini. I also assume that the user knows how to access the NAS terminal and the status of the missing RAID was good when the disks where removed.
Phase 0: Diagnostic and Array Discovery
Before attempting to mount or register the missing volume, you must determine how the Linux kernel is currently interacting with the reinserted disks. Often, the kernel automatically flags the discovered partitions but locks them inside a temporary, high-numbered Multi-Disk node (such as /dev/md127 or /dev/md126).
1. Check Active Storage Arrays
Run the following command to view the current status of all Multi-Disk devices recognized by the kernel:
bash
cat /proc/mdstat
Scenario: You might only see your main volumes (e.g., md0, md1, md3). However, if a rogue array appears as md127 or md126 showing an inactive or unmapped state alongside your missing drive partitions, it must be cleared.
2. Inspect Block Devices and Partitions
To identify which physical disks are unmapped and belong to your missing array, list all available block devices:
```bash
Use fdisk to review partition layouts
sudo fdisk -l
``
Identify the component storage partitions (usually the largest data partition on each drive, e.g.,/dev/sdd4,/dev/sde4,/dev/sdf4`) that correspond to the missing volume.
3. Verify and Stop the Ghost Array
If the drives are trapped inside a temporary container like /dev/md127, you must inspect its details and gracefully shut it down to release the disk resources:
```bash
Verify the underlying metadata of the ghost array
sudo mdadm --detail /dev/md127
Stop the array to free up the physical drives/partitions
sudo mdadm --stop /dev/md127
```
⚠️ Note: If you skip stopping the ghost array, any subsequent assembly command will fail with a "Device or resource busy" error.
Phase 1: Kernel-Level Assembly and Manual Mount
Once the disk partitions are completely released from temporary kernel locks, force the Linux subsystem to properly assemble the underlying RAID array under a standardized logical node.
```bash
1. Assemble the RAID array using an available floating logical MD node (e.g., /dev/md2)
sudo mdadm --assemble /dev/md2 /dev/sdd4 /dev/sde4 /dev/sdf4
cat /proc/mdstat
2. Create a clean mount point directory in the root tree
sudo mkdir -p /volume2
3. Mount the Btrfs file system manually to verify data health
sudo mount /dev/md2 /volume2
```
💡 Result: If successful, the array will report a healthy state (e.g., [UUU]), and your files will become instantly accessible via the Command Line Interface (CLI) under /volume2.
Phase 2: Gathering Configuration Data for Generalization
To adapt this procedure for your specific system or share it as a template, collect the following four parameters from your operating environment to build the permanent ADM metadata block.
1. Extract the Exact RAID UUID
The UUID specified in the system configuration files must precisely match the metadata blocks written onto the disk headers. Query the newly assembled device:
bash
sudo mdadm --detail /dev/md2 | grep -i "UUID"
Example Output: UUID : 12345678:abcdef01:23456789:abcdef01
2. Map the ASUSTOR "Index" (Drive Bays)
The Index parameter represents the 0-indexed sequence of the physical drive bays where the array resides. ASUSTOR maps drive letters to numeric indices sequentially:
* Bay 1 (sda) ➔ 0
* Bay 2 (sdb) ➔ 1
* Bay 3 (sdc) ➔ 2
* Bay 4 (sdd) ➔ 3
* Bay 5 (sde) ➔ 4
* Bay 6 (sdf) ➔ 5
Application: For an array sitting in physical Bays 4, 5, and 6, the resulting string must be defined as Index = 3,4,5.
3. Match the RAID "Level" Value
ADM reads standard numerical definitions to determine RAID layouts:
* RAID 1: Level = 1
* RAID 5: Level = 5
* RAID 6: Level = 6
* Single / JBOD: Level = -1
4. Determine the "Raid" Key Identifier
The Raid variable in the configuration block matches the integer value of the Linux Multi-Disk device wrapper.
* If your array is running under /dev/md2, use Raid = 2.
* If it is running under /dev/md3, use Raid = 3.
Phase 3: Permanent Registration in ADM 5 UI
ASUSTOR abstracts persistent configurations using an internal symbolic link called .volsystem, which physically routes system parameters to the hidden storage array mounted at /volume0.
```bash
1. Back up the original storage configuration file
sudo cp /volume0/usr/etc/volume.conf /volume0/usr/etc/volume.conf.bak
2. Open the configuration file using a text editor
sudo nano /volume0/usr/etc/volume.conf
```
Scroll to the very end of the file, insert a blank line after the final active volume section and add the missing configuration block.
⚠️ Warning: These values must be adjusted according to your configuration and depend on factors such as volume, RAID level, file system and cache configuration. Use the presented values as a starting point.
ini
[volume2]
Level = 5
Raid = 2
Total = 3
Option = 0
Ftype = btrfs
UUID = 12345678:abcdef01:23456789:abcdef01
Index = 3,4,5
Cachemode = 0
S0UUID =
S1UUID =
CLevel = 0
CState = -1
CDirty = 0
CUUID =
Cnumber = 0
CIndex =
Cseqcut = No
CsizeMB = 0
Phase 4: Validation & Persistence Verification
- Hot Detection Check: Because the ADM 5 framework utilizes background file monitoring (such as
inotify), saving your modifications to volume.conf will trigger the web GUI daemon to instantly parse the changes. The volume will dynamically materialize inside the Storage Manager app in real-time.
- Persistence Test: To guarantee the automation routine executes correctly during cold boots without requiring manual shell access, perform a graceful reboot:
bash
sudo reboot
Final Verified State
Upon reboot, ADM's built-in initialization sequences natively read the injected parameters inside /volume0/usr/etc/volume.conf, automatically assemble the correct multi-disk array, and securely mount the Btrfs layer onto /volume2. Full visibility is permanently restored across File Station, system services, and network shares.
MRiscoC with the assistance of Gemini