Hiya, I have a big problem I cannot seem to get around. I tried to move to internal boot using one of the NVMe's I have on the system that was in a cache pool. I rebooted the system, and now I have no boot device, no cache pool, and somehow I have a message saying: All existing data on this device will be OVERWRITTEN when the array is started. On my array, which I DO NOT want to happen lol.

I am a BIG novice. I set this server up watching a YouTube video 3 years ago and have not touched it bar using it to add my blurays for media storage, so please bear with me as I am not clued up on the Linux and Unraid side of things.

If anyone would be able to advise me on how to get around getting things back to normal, I would be forever grateful, as I have A LOT of media I would like to keep


This is the message I have about overwriting data:



Here are the errors I have with the internal boot:



You can see in the unasigned there is an NVMe. I think this was supposed to be in the cache pool. My memory stick is there too but not used as the boot, as I can remove it and it still boots up to unraid.


Thank you

Hi FlunkyBob, first the good news, then what I think happened, then what I'd do next.

1. Your media is not in immediate danger. The red "All existing data on this device will be OVERWRITTEN" line in your first screenshot is only on the Parity slot (sdb), not on Disk 1/2/3. Parity holds no files, it is only the checksum drive. That message means Unraid intends to (re)build parity when the array starts. Your three data disks do not carry that warning, and Unraid never formats a data disk unless you tick the format box yourself.

But please do not start the array yet. Your four drives are the same model (ST20000NT001, 20 TB). The parity warning usually means the array configuration was reset ("new array" Tools->NewConfig?). If the drive that is now in the Parity slot used to be one of your data disks, starting the array would overwrite it with parity. Your diagnostics will show whether the slots still match the original assignment. Until then, leave the array stopped and don't click Format or Erase anywhere.

2. What the internal boot wizard did probaly to the NVMe. When you pick a drive in the wizard, Unraid wipes it completely and writes a new partition table (BIOS boot + EFI + a ZFS boot partition that now holds your /boot configuration + a data partition for the new pool). The wizard shows "All selected devices will be formatted." before it runs. So whatever was on the NVMe ending in …67B6D2 is gone, and that is the drive your server now boots from (that's why it still comes up with the USB stick removed).

The second NVMe (…647ACC) is maybe still in its old state: Unassigned Devices shows it with an intact btrfs partition. If your cache pool was a two-drive btrfs pool with Unraid's default RAID1 profile, each drive held a full copy, so your appdata/docker/VM data is very likely still on that drive. If the pool was a single drive or RAID0, the part that lived on …67B6D2 is lost.

3. Why the "Boot Pool" section looks like that. Your second screenshot shows two boot pools, "Bootnvme" (1 slot) and "New" (2 slots), and every member says "no device / Missing". That means the config still remembers the serial numbers, but the slots are empty. The two pool names suggest the wizard was run twice (once with one drive, once with both). The leftover pool definitions (/boot/config/pools/bootnvme.cfg and new.cfg) are what is blocking things. I'd rather look at your diagnostics first.

4. What to post / check now.

• Tools → Diagnostics → download the zip and attach it here (do this before changing anything else).

• What was the cache pool called before, and did it have both NVMes in it?

• Did you run the wizard more than once, and did you change any array assignments yourself after the reboot?

• Do you have any older backups at all, for example a copy of the USB stick, an Unraid Connect flash backup, or a backup of appdata and domains? Not needed to fix the array, but good to know what we can fall back on.

• Keep the USB stick plugged in: it still holds your licence and a copy of the configuration from the moment the wizard ran, so it is your fallback (you can boot from it via the BIOS boot menu if needed).

With the diagnostics maybe we can go through it in a safe order: fix the pool config, get the surviving NVMe mounted again, confirm the array slots, then start the array and let parity rebuild.

Edited 20 hours ago20 hr by UnraidSecretaryOffice

Thank you for the quick reply @UnraidSecretaryOffice

- I have attached the diagnostics zip to this post.
- I unfortunately do not remember the name of the pool. I think it was called 'cache', but I'm not too sure.
- I did run it more than once. I feared I did it wrong the first time, and running again it would correct the issue.
- I have an older backup of the USB stick, and appdata is backed up by Unraid on the server.

As for the "All existing data on this device will be OVERWRITTEN" warning, I did do the tools -> newconfig, as it thought that might allow me to start again with the drives. It was foolish of me, as I should not mess with things I know nothing about.

I have got the missing drive back up and showing in the cache pool, and the drive is in the boot pool now, where I originally put it

Please see the screenshot:

mainmediaserver-diagnostics-20261011-1452.zip

Thanks for the diagnostics, they answer the important questions.

1. Your array assignment looks right, but let’s make it certain before starting. SMART keeps a lifetime write counter per drive. The drive now in the Parity slot (…ZVT8EY4P) has written about 157 billion sectors; the other three about 45, 50 and 60 billion. Those three add up to 155.6 billion, almost exactly the parity drive’s number. That is what you’d expect from Unraid parity, because every write to a data disk is also written to parity. So …ZVT8EY4P was very likely your parity drive all along.

To make it certain, run this in the terminal (the >_ icon top right) and post the output:

lsblk -o NAME,SIZE,FSTYPE,SERIAL

The three data disks should show a file system (xfs or btrfs) on their partition line (sdX1); the parity drive’s partition should show nothing in the FSTYPE column. If that matches, a parity rebuild is harmless for your Parity-Disk because there ist no filesystem an terefore no data... If the Parity drive shows xfs or any filesystem-type, don’t start the array; post the output first.

2. The cache pool almost certainly held nothing. The surviving NVMe (…647ACC) has written 11.7 MB in total in its entire life (12,000 power-on hours), and six of your seven shares are set to “Use cache: no” (appdata, domains, isos and your media shares all live on the array). The diagnostics don’t record the cache setting of the “system” share, but with 11.7 MB ever written to that NVMe, your Docker image probably cannot have lived there. So the NVMe the wizard wiped very likely took no data with it - i hope.

3. Clean-up, in this order:

Settings → Disk Settings → “Enable auto start” = No (it already is; just leave it NO). Also, so that nothing starts on its own while we sort this out: Settings → Docker → “Enable Docker” = No → Apply, and Settings → VM Manager → “Enable VMs” = No (your diagnostics show VMs are already off, Docker is still on). We switch them back on at the end.

Then in your Terminal:

mv /boot/config/pools/new.cfg /boot/config/pools/new.bak

then Main → Reboot. After the reboot the “New” pool shoud be gone; “Cache” and “Bootynvme” stay.

Only after the lsblk check in step 1 looked right: Main → Start (Maintenance mode unticked, no other boxes). Unraid will mount your three data disks right away, so your shares are back immediately. In the background it starts rebuilding parity, which takes many hours for 20 TB; you can use the server normally while that runs (if later anything is on board like appdata system domains isos etc.).

After the start, “Bootynvme” will be listed as “Unmountable: unsupported or no file system”: that is the empty / destroyd data part of your boot NVMe. “Cache” (…647ACC) will either mount in degraded mode (it still carries half of the old two-drive pool) or also show as unmountable, depending on how the old pool was set up. Either way there is nothing on it. When the unmountable list contains only these pool names and never Disk 1/2/3, you can tick the “Yes, I want to do this” box that sits next to the Format button and press Format (or post Screenshot hier first if you'r unsure, but first check if all our shares are on stage).

Once parity has finished, set the shares you want on the SSD (e.g. appdata, system) to use a pool, and turn auto start back on.

One thing to avoid: never tick “Yes, I want to do this” next to Start will remove the missing pool disk while the old pool is still listed; on a 7.3.3 test server in your situation that made the array start hang until a reboot. With new.cfg moved away, that option should doesn’t appear anymore.

Edited 17 hours ago17 hr by UnraidSecretaryOffice

Here is what lsblk -o NAME,SIZE,FSTYPE,SERIAL gave me:

NAME SIZE FSTYPE SERIAL

loop0 736.1M squashfs

loop1 308.3M squashfs

sda 58.9G A20052630D650C58

└─sda1 58.9G vfat

sdb 18.2T ZVT8EY4P

└─sdb1 18.2T xfs

sdc 18.2T ZVTASG8C

└─sdc1 18.2T xfs

sdd 18.2T ZVT894XM

└─sdd1 18.2T xfs

sde 18.2T ZVT7XXNE

└─sde1 18.2T xfs

sr0 1024M KLON5PA4401

zram0 0B

nvme0n1 931.5G 25014D67B6D2

├─nvme0n1p1 1M

├─nvme0n1p2 510M vfat

├─nvme0n1p3 127.5G zfs_member

└─nvme0n1p4 803.5G

nvme1n1 931.5G 25014D647ACC

└─nvme1n1p1 931.5G btrfs

The NVMe's were there to help with the system to run faster. I must admit the system is very slow and I think this is because of them not being in use, maybe?


If this is ok, please let me know if I should continue with step 3.

Thank you

Please don’t start yet. Your lsblk output doesn’t settle it: the parity drive is the XOR of the three data disks, and with three xfs disks the xfs signature survives that, so parity shows “xfs” too (I reproduced that on a test server). Let’s find the parity drive the simple way instead: start the array once without parity.

1. Settings → Docker → “Enable Docker” = No → Apply (so nothing starts on its own; we turn it back on at the end).

2. Terminal (the >_ icon top right):

   mv /boot/config/pools/new.cfg /boot/config/pools/new.bak

   then Main → Reboot. The “New” pool is gone afterwards and the Start button is usable again.

3. On Main, set the Parity slot to “unassigned”, and assign that drive (…ZVT8EY4P) to Disk 4. Disk 1–3 stay as they are. Now all four drives are data disks and nothing can be overwritten.

4. Main → Start. Then look at the four disks (Main shows Used/Free per disk; the shares or /mnt/disk1 … /mnt/disk4 show the files etc.). Three of them contain your data. The fourth either shows “Unmountable” or mounts but shows no sensible content: that one is your parity drive. Don’t format anything, just note which serial it is. And its a good Point to check if all your share are live again.

5. Main → Stop. Tools → New Config → “Preserve current assignments”: All → tick the box → Apply. Back on Main, set the Disk slot of the drive from step 4 to “unassigned” and assign that drive to Parity (the other three stay where they are, the pools stay too), then Start. Parity rebuilds in the background, your shares are available meanwhile.

6. Then as in my earlier post: “Bootynvme” (and maybe “Cache”) show as unmountable; when the unmountable list contains only those pool names and no Disk 1/2/3, tick the box next to Format and format them. Finally turn Docker back on and set “Enable auto start” to Yes.

If anything looks different from what I describe, post a screenshot before clicking on.

I have set Disk 4 back to the parity drive and started the new config


I am however, getting errors coming up like those in the screenshots

How should I proceed? I have paused parity sync for the moment

That all looks as expected, nothing new is broken: Disk 1, 2 and 3 are mounted with your data (9.69 TB, 6.51 TB, 6.51 TB used), …ZVT8EY4P can being rebuilt as parity, “Cache” is mounted in degraded mode with only 5.91 MB on it, and “Bootynvme” is unmountable because the wizard wiped that NVMe and created a new, still unformatted data partition on it.

Now let’s check that everything you care about is back before we tidy up:

Open the Shares tab: are all your shares listed, and when you open one (the folder icon on the right) are your files there?

Settings → Docker → “Enable Docker” = Yes → Apply, then open the Docker tab: do your containers show up and start? Open one or two of them (e.g. your media server) and check they work.

Tell me how far you come. If something is missing, don’t change anything, just post it.

After that, we solve the issues in Main.

Edited 15 hours ago15 hr by UnraidSecretaryOffice

7 minutes ago, UnraidSecretaryOffice said:

are all your shares listed, and when you open one (the folder icon on the right) are your files there?

The "folder icon" is on the LEFT. It looks like a square with an arrow sticking up to the right.

I have checked and tested this morning, and all seems fine apart from the cache disk error showing on the Main

My shares are there, although with a warning that the parity is not fully finished, and my Docker apps all work fine

Good, that's the main thing done: your data is there and your containers run. The warning icon on the shares just means the files aren't parity-protected yet; it disappears when the parity sync has finished. The cache error on Main is the old half-pool, we clean that up now. Order:

1. Check Main → Array Operation: if the parity sync is still paused, click Resume or Start. Let it finish before any reboot; the progress is shown there.

2. Meanwhile you can already format the empty data-NVMe partition: under Array Operation it says "Unmountable disk present: Bootynvme". Tick the "Yes, I want to do this" box next to Format and press Format. Only that empty partition gets formatted; Disk 1–3 and Cache are mounted and not affected.

3. Cache clean-up, also possible while the sync runs. Terminal (the >_ icon):

btrfs balance start -f -dconvert=single -mconvert=single /mnt/cache
btrfs device remove missing /mnt/cache

Both finish in seconds on an empty pool.

1. After the parity sync is finished: Main → Stop. Click "Cache", set Slots to 1, and make sure …647ACC sits in Device 1 (if it jumped to "unassigned", pick it in the Device 1 dropdown). Main → Start. The Cache pool should now show ONLINE without the DEGRADED warning and the error is gone.

2. Finally Settings → Disk Settings → "Enable auto start" = Yes, and run Fix Common Problems once more (Settings → User Utilities). If it still lists something, post a screenshot.

Then you’re back to normal. To be clear about what you end up with: Unraid boots from the first NVMe (…67B6D2), whose remaining space is the pool “Bootynvme”; the second NVMe (…647ACC) is the pool “Cache”. Nothing is mirrored, neither the boot nor the pools, so each NVMe is on its own.

If your original goal was a mirrored boot on both NVMes, that is possible in 7.3 as a second step (the second NVMe would be wiped and added to the boot pool as a mirror). Let’s get the current state clean first; if you want the mirror, say so and we go through it separately (maybe after your backup-run....).

Edited 2 hours ago2 hr by UnraidSecretaryOffice

One correction to the cache clean-up.

1. Cache pool: don't change the slot count, reimport the pool instead

The device the pool lost is still recorded inside the btrfs filesystem. Remove it there first, then let Unraid import the pool again as a single device.

With the array started (this is fine while the parity sync runs):

btrfs balance start -f -dconvert=single,soft -mconvert=dup,soft /mnt/cache

btrfs device remove missing /mnt/cache

btrfs filesystem show /mnt/cache

The last command should list only one device, with no "missing" line. Use dup for metadata, not single. On a one-device pool, dup keeps two copies of the metadata, which is the normal setup.

After the parity sync has finished (stopping the array interrupts the sync):

on main click on the first device for that pool and then "remove pool"

back on main, create a new pool with the same name and 1 slot

assign the remaining pool device, leave the filesystem set to auto

start the array to import the pool

The pool should now import as a normal single-device pool, and the error on Main should be gone. All your shares use the array, not the cache, so nothing is affected while the cache is unassigned for a moment.

For the future, yhe internal boot wizard erases every device you select. Before you run it, make sure the device is not part of an existing pool, or move that pool's data off first. When something looks wrong, post diagnostics before you use Tools → New Config. New Config is rarely needed, and it removes the record of which drive was parity.