I don't even know where to start. I added a second parity drive and my older parity 1 failed. I had a disk in the array that had no data written to it so I shut down the array, moved the drive to parity, and ran new config. at about 90% drive 9 completely failed. I shut down the server, checked all cables and restarted it. Drive 9 definitely failed. I shut down the server and replaced drive9(yes I know total data loss) with a spare. after restarting the server everything was ok, BUT my shares are there, but all the share info is not, and my dockers don't work. I am at a loss. I will attach diagnostics. This was after I rebooted it, I will add a post with fresh diagnostics too. dual parity is currently rebuilding with 8 hours to go.

schmittnas-diagnostics-20260404-2231.zip

Edited April 5Apr 5 by Juscuz17

Her e is a fresh diag.

schmittnas-diagnostics-20260405-1149.zip

Edited April 5Apr 5 by Juscuz17

Your Docker/VM related shares - appdata, domains, system - have some files on the array. Possibly some of those files were on the now gone disks.

Ideally, those Docker/VM related shares would have all files on cache or other fast pool, with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open.

Go to Settings and disable Docker and VM Manager.

Set appdata, domains, system shares to Primary:cache; Secondary:array; Mover action:array->cache.

Go to Array Operation and run Mover. Wait for it to complete, post new diagnostics.

2 minutes ago, trurl said:

Your Docker/VM related shares - appdata, domains, system - have some files on the array. Possibly some of those files were on the now gone disks.

Ideally, those Docker/VM related shares would have all files on cache or other fast pool, with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open.

Go to Settings and disable Docker and VM Manager.

Set appdata, domains, system shares to Primary:cache; Secondary:array; Mover action:array->cache.

Go to Array Operation and run Mover. Wait for it to complete, post new diagnostics.

I have to wait 8 hrs for the parity sync to finish to run mover, I did everything else. Thank you! I will post as soon as I can.

App Data was set to cache only.

Just now, Juscuz17 said:

App Data was set to cache only.

Yes I know, but it already had files on the array. "Only", won't move anything, since there is no Mover action because no Secondary

Just now, trurl said:

Yes I know, but it already had files on the array. "Only", won't move anything, since there is no Mover action because no Secondary

OK, that's what I thought. I am I correct that I cannot move anything till parity is done?

Technically you can move while syncing parity, but it will slow down parity rebuild and slow down mover since it would have to seek to the place it needs to read/write for the move, and seek to the place it needs to write parity.

So, just let if finish parity sync.

If you lost system share and it had to be recreated that would be the most likely reason for all dockers to be gone. As long as you have appdata, they can be easily reinstalled and work just as before by using Previous Apps on the Apps page since the executable code stored in docker.img will just be downloaded again.

Just now, trurl said:

Technically you can move while syncing parity, but it will slow down parity rebuild and slow down mover since it would have to seek to the place it needs to read/write for the move, and seek to the place it needs to write parity.

So, just let if finish parity sync.

If you lost system share and it had to be recreated that would be the most likely reason for all dockers to be gone. As long as you have appdata, they can be easily reinstalled and work just as before by using Previous Apps on the Apps page since the executable code stored in docker.img will just be downloaded again.

OK! I also have a current APP Back up.

schmittnas-diagnostics-20260405-2317.zip

Doesn't look like you had run Mover yet.

5 hours ago, trurl said:

Doesn't look like you had run Mover yet.

I ran Mover waited a while then ran Diagnostics. Here is a fresh pull.

schmittnas-diagnostics-20260406-1352.zip

9 minutes ago, Juscuz17 said:

I ran Mover waited a while

On 4/5/2026 at 11:57 AM, trurl said:

run Mover. Wait for it to complete, post new diagnostics.

1 hour ago, trurl said:

  1 hour ago, Juscuz17 said:

I ran Mover waited a while

  On 4/5/2026 at 11:57 AM, trurl said:

run Mover. Wait for it to complete, post new diagnostics.

Mover is scheduled to move every night at 0300, I manually initiated it, and came back and there was no activity on any drives so I ran diag and posted it. that was about 11pm. the mover would have automatically moved anything at 0300 also, so I posted another diag a bit ago after your post. I made sure docker was shut down and invoked the mover again. I will check in when i get home and see what the log says.

When you run it yourself using the MOVE button in Array Operation, the button will become disabled while it is running, and enable again when it is complete.

The button was only grey for a few seconds, but the log only said start mover, never mover ended or anything. I will be home in bit, I will triple check everything you told me and run the mover again and note how long the button is disabled. There isn't much to move right now, so it won't take long.

Edited April 6Apr 6 by Juscuz17

Sorry, I left out a very important instruction.

Nothing can move open files.

Go to Settings and disable Docker and VM Manager.

Then run mover, wait for it to complete, post new diagnostics.

schmittnas-diagnostics-20260406-1741.zip

OK, the mover ran for a split second, then stopped. Docker and VM manager are disabled.

Apr  6 17:41:14 SchmittNAS webgui: File_put_contents_atomic failed to write / rename /mnt/bad/1691912352.tmp
Apr  6 17:41:14 SchmittNAS root: Fix Common Problems: Error: Unable to write to bad

Looks like your bad pool may be readonly.

It has no user shares, no user shares are configured to use it, yet it is 85% full. What can you tell us about that pool?

10 hours ago, trurl said:

Apr  6 17:41:14 SchmittNAS webgui: File_put_contents_atomic failed to write / rename /mnt/bad/1691912352.tmp
Apr  6 17:41:14 SchmittNAS root: Fix Common Problems: Error: Unable to write to bad

Looks like your bad pool may be readonly.

It has no user shares, no user shares are configured to use it, yet it is 85% full. What can you tell us about that pool?

That is failed disk9. I moved it to a pool to see if I could get any data off it. I cannot. So I just haven't removed it yet.

domain and system still on the array.

Try restarting the array to refresh the shares, then

On 4/5/2026 at 11:57 AM, trurl said:

run Mover. Wait for it to complete, post new diagnostics.

2 hours ago, trurl said:

domain and system still on the array.

Try restarting the array to refresh the shares, then

I will as soon as I get home. I cannot do that from work.

I don't mean reboot, just Stop and Start.

3 hours ago, trurl said:

I don't mean reboot, just Stop and Start.

schmittnas-diagnostics-20260407-1739.zip

Plex still is not responding. I restored the whole docker, then updated it. it will start but the web ui says cannot connect.

OK, appdata, domains, system all on cache now.

Don't know if you are familiar with these:

Docker troubleshooting | Unraid Docs

This page offers troubleshooting guidance specifically for Docker containers on Unraid, managed by the Unraid team. For advanced troubleshooting, in-depth technical details, or topics beyond the Unrai