trurl

Maybe anonymized @Mibix examine your syslog at that timestamp and see if you can identify the file

No way to know how well disk2 emulation might work without trying. Any linux should be able to read any of the other disks assuming there are no problems with them. Unraid is linux and if we can get the array started one way or another we can try to read them that way. If we have to give up completely on disk2 we can just New Config and it will let us start the array without that disk. Or if we can get it to emulate disk2 then the array will be started. Those other drives look healthy, but no way to know if the filesystems on them are mountable without starting the array.

The diagnostics only has logs from yesterday so can't tell what happened before that. That's where it gets a little tricky. We would have to force Unraid to accept parity and then disable disk2 instead so we could try to rebuild it. This takes multiple steps that have to be followed exactly, and it isn't really documented except in other forum threads where we have used this method. I will give those instructions when we are ready to try them.

I say this because if disk2 went missing first, disk2 would be the disabled/emulated drive. If parity has been disabled for a while, it might be too out-of-sync to do a good rebuild of disk2 even if the parity drive were really good. Another way to recover the data for disk2 would be to get the array to emulate disk2 from the parity calculation and copy the emulated data somewhere off the array, not to other array disks since that would require parity updates which should be avoided considering the poor state of parity. But of course, the poor state of parity and the fact that it might be out-of-sync, would make it difficult to accurately emulate disk2, whether for rebuilding or just for copying its emulated data.

Parity must have become disabled before disk2 went missing. Do you know how long parity has been disabled?

Depends on how we define "recover". One possible definition would be to rebuild disk2 onto that new drive from existing parity plus all other drives. Whether parity works well enough to allow that remains to be seen, but it may be our only hope if original disk2 can't be read. And if nothing we can do can recover disk2, then you could use that new drive as parity in a New Config that didn't include original disk2.

You will also need to replace parity after we see if we can recover disk2. So another 12TB might be needed. We will see how it goes.

One of the great features of Unraid is each data disk in the parity array is an independent filesystem that can be read all by itself. So there is every reason to expect that all of your other data disks have their data intact.

Any progress on getting disk2 connected?

Yes, but I guess it is worth at least trying to rebuild disk2 from that (bad?) parity. Do you have a spare 12TB disk? Bedtime for me. We will see what can be done tomorrow.

If you click on parity and go to its Attributes, I think you will see all these problems: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 100 100 010 - 236 187 Reported_Uncorrect -O--CK 001 001 000 - 5665 197 Current_Pending_Sector -O--C- 097 097 000 - 1652 198 Offline_Uncorrectable ----C- 097 097 000 - 1652 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Self-test routine in progress 80% 18252 -Has it completed extended test yet?

Other array disks SMART looks OK. I think it's unlikely parity can be expected to rebuild anything so probably disk2 is lost unless you can read it. Do you have backups? Parity is not a substitute for backups.

SMART report for parity looks very bad don't know why you think it is healthy. Do any other drives show SMART (👎) warning on the DASHBOARD page?

Are you sure disk2 is really dead? Is it still plugged in? I don't see it in those diagnostics. See if you can reconnect it and check if you can see it in BIOS.

Do you have some docker constantly restarting? Check their uptimes on the Docker page.

Attach Diagnostics ZIP to your NEXT post in this thread.

After you fix whatever caused this, I recommend moving some data from disk4 so it has more free space. If the disk ever needs to have its filesystem repaired, it will need some free space to work with.

A little late to this thread, but just thought I would comment on the settings you have for your UPS. The purpose of UPS isn't to allow you to run on batteries as long as possible. The purpose of UPS is to allow you to run long enough to get through very brief power outages, and to allow your server to shutdown cleanly if the outage is more than brief. The parameter you should be setting is Time on battery before shutdown (seconds). 300 seconds or less is my recommendation. You need to figure out how long a clean shutdown actually takes. You don't want to allow the battery to run down very far. It is not good for the battery, it takes longer to recharge, and you don't want to restart your server on an UPS with depleted battery.

If you want us to take a closer look for you, start the array in normal mode and post new diagnostics.

Was this on the emulated disk? That output doesn't look all that good. I think there is probably a lot of lost+found. You can examine the contents of the emulated disk by starting the array in normal (not maintenance) mode. Then you can decide if the contents of the emulated disk are what you actually want, or if you would be better off with the contents of the physical disk, which you said didn't have any lost+found.

Please use the webUI instead of command line. Are you trying to run repair on the physical disk or the emulated disk? The commands you have specified will not check either device. Not sure what you had in mind with those commands, since you just mount then unmount without doing anything. If you run check on the sdb1 device/partition, that will be the physical disk designated sdb. You must check the md device to check the emulated disk. Please use the webUI instead of command line, whether checking an assigned device or an unassigned device.

Any folder at the top level of a disk or pool is automatically a user share. Probably you have some container host mappings set to /mnt/cache/data and /mnt/cache/dmz And since you didn't make any settings for those shares you accidentally created, they have default settings (cache-no)

I have split your post into its own thread since it's likely the plugin is not the problem. The way you configured some app would be the actual reason. Attach Diagnostics ZIP to your NEXT post in this thread.

Attach Diagnostics ZIP to your NEXT post in this thread.