Hi.

I got an issue on my server and lost access to my share.

I need help safely shutting down, recovering my data, and diagnosing the root cause.

Few days ago, in the morning, i noticed that i cannot access to my share.

I checked webGUI and noticed that Disk 1 is disabled.

People told me that it could be the SATA cable issue, so i started shutdown the server.

Then the server started stoping the array.

But it never ends until now, have been stuck at Array Stopping•Sync filesystems...

The server log only shows error like below;

May 17 04:40:04 Tower kernel: md: disk0 read error, sector=976762672

The server have been stuck this state for few days now.

I want to know how to safely shut it down so I can replace the sata cable of the Disk 1 so I can see if it actually caused the problem.

I mainly used my server as simply a file server for last few months, and didn't any unusual stuff before the day i noticed the issue.

My array is consist of 1 16TB parity, 1 16TB Disk 1 (which is disabled now), 2 1TB Disk 2 and 3 which is mostly unused, 1 500GB SSD cache.

All of disks are xfs and cache is btrfs.

The setting screen of Disk 1 shows it's mounted.

Attributes tab has only one line;

Smartctl open device

/dev/sdc failed

The parity says it's valid, but the last check completed was almost a year ago. (I will definitely schedule a parity check more frequently after this issue solved...)

And the error count of the parity in the main screen looks too big. it's 6,795,035,043. I don't remember the count before the issue happens, but this is not okay I think?

I though if the failure is happened on the disk 1, it would be emulated and I can still access to my share, as long as parity is valid.

But now, my share is empty and I cannot access.

What I want to know and need help is;

• Since the WebGUI is completely stuck on "Sync filesystems", how can I safely force a shutdown without causing further data loss?

• Why is Disk 1 not being emulated? Is it because the Parity drive (disk0) is also failing based on the log errors?

• Once I manage to reboot, what is the best way to test if this is a bad SATA cable/power split issue or a total hard drive failure?

Thank you so much for any advice. I am a beginner of Unraid so please tell me if I'm lacking some info.

tower-smart-20260517-0530.zip

Please post the diagnostics.

Sorry, I thought I did post the diagnostics, but it was a smart report...

tower-diagnostics-20260516-1637.zip

Parity disk is inaccessible; power down, check/replace its cables, and post new diags.

I tried to power it down from gui but it have been stuck at Array Stopping•Sync filesystems... for days (I wrote more details in the original post)

And that is exactly the first question I wanted to ask, how should I power it down safely?
Am I okay to forcibly shutdown it by long pressing the power button, for example?

Also, I thought it was Disk 1 having some trouble because it's disabled, but does it looks like it was actually the parity?

If the server cannot shut down cleanly, you will need to force it.

I replaced the parity drive's SATA cable with a spare one I had.

Also, I noticed that the SATA port latch on Disk 1 is broken, so the cable comes off very easily (it doesn't lock in place).

After rebooting the server, Disk 1 is still disabled.
Array is not started.

Here are the new diagnostics taken right after the reboot.
(I just noticed that my cache is missing. I think it just became loose while replacing the sata cable on the parity. I'll fix it later.)

Now, what should I do next to fix the Disk 1?

tower-diagnostics-20260519-2328.zip

Edited May 19May 19 by chropass

SMART for parity looks good, start the array to see if the emulated disk1 is mounting and post new diags.

Here's a new diags.

I can see folders in my share now.

But I think not all of the share is restored, and disk 1 is still disabled.

Because the free space of disks other than disk 1 is mostly unused, I believe most (or probably all?) of the data is stored in disk1.

Is there any way to restore the date from disk1?

tower-diagnostics-20260520-0741.zip

Edited May 19May 19 by chropass

Emulated disk1 is not mounting; check filesystem on it.

I checked the filesystem of disk 1 and fixed it. (I had to clear log stuff)

After that, it showed something like "no corruption on the filesystem". (sorry i didn't save the exact message somewhere)

Then I stopped array and restarted without maintenance mode.

Now I guess I can see everything I can remember on share!

But disk 1 is still disabled.

I really appreciate you and glad that at least my data is not lost.

Now, what should i do next?

(diags is taken after the array restarted)

tower-diagnostics-20260521-2011 (1).zip

Fixing the filesystem created a lost+found share on disk1. These are files that repair couldn't identify so they will be random folder and file names.

On the User Shares page, click Compute... for the lost+found share, wait for it to complete, and post the results.

Check the emulated disk contents, and the lost+found folder like trurl mentioned, and if you are happy with the contents, you can rebuild:

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

I found lost+found but there's nothing there...

But i can do see there's something in lost+found folder, if I browse it from Main->Disk1.

I don't recognize every one of the files in the folders but like half of them were definitely looked familiar...

Did I wrong something when i checked lost+found on Share?

35 minutes ago, chropass said:

I don't recognize every one of the files in the folders

Neither did repair

1 hour ago, trurl said:

These are files that repair couldn't identify so they will be random folder and file names.

36 minutes ago, chropass said:

found lost+found but there's nothing there...

4.6GB is more than nothing, but not a lot comparitively.

Linux 'file' command can try to determine what type of contents a file might have so you can try to open it in an appropriate application to see if you know what it is.

56 minutes ago, JorgeB said:

Check the emulated disk contents, and the lost+found folder like trurl mentioned, and if you are happy with the contents, you can rebuild:

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

The emulated contents are exactly what will be rebuilt, so the lost+found will still be there after rebuild.

I want to repair every files including the ones that I don't recognize at this point.

16 minutes ago, trurl said:

The emulated contents are exactly what will be rebuilt, so the lost+found will still be there after rebuild.

I can see the files inside lost+found when I browse it via Main -> Disk 1, but when I try to access it via Shares, it's empty or says "Invalid path."

Does this mean those specific files are currently not being emulated?

If so, should my next step be to get those contents to show up correctly under the lost+found share first?

Edited May 21May 21 by chropass

48 minutes ago, chropass said:

Disk 1, but when I try to access it via Shares, it's empty or says "Invalid path."

That suggests there's still a filesystem issue, reboot, try accessing via shares again, and post new diags.

I reboot and check lost+found via Share, but it's still only "Invalid path."

tower-diagnostics-20260522-0216.zip

I thought you meant the normal shares. Can you access the other data on disk1, the one outside lost+found? Lost+found are lost files that xfs_reapir could not correctly fix.

Sorry for the confusion, maybe my English wasn't good enough

Yes, I can see many files and directories exist there.

I also noticed that actually many files I can see in Share are actually located at disk 1.

I thought it's emulated by parity and not actually referencing disk 1, since disk 1 is still disabled...

Edited May 21May 21 by chropass

4 hours ago, chropass said:

I also noticed that actually many files I can see in Share are actually located at disk 1.

If the disk is being emulated then it is referencing the emulated version of the disk, not the physical one.

1 hour ago, itimpi said:

If the disk is being emulated then it is referencing the emulated version of the disk, not the physical one.

It might be useful to see if physical disk can be mounted as an Unassigned Device. Could be parity is suspect and that is the reason the emulated disk was unmountable.

Disk1 is mounted (I saw the filesystem is stated as mounted, in Main->disk1 setting screen), disabled, and emulated, if I'm understanding correctly.

9 hours ago, trurl said:

It might be useful to see if physical disk can be mounted as an Unassigned Device. Could be parity is suspect and that is the reason the emulated disk was unmountable.

Now I installed unassigned devices app and restarted the array with disk1 unassigned.

Now I can browse it.

Compared to what I can see in Share, it looks like some files/directories are missing.

Also there's no lost+found folder.

Edited May 22May 22 by chropass

If the contents from the actual disk look better than the emulated disk, instead of rebuilding, you can do a new config and re-sync parity:

-Tools -> New Config -> Preserve current assignments: All -> Apply

Then go to main, reassign disk1, make sure all the other assignments are correct, check "parity is already valid," start the array, and run a correcting parity check; some sync errors are expected.