trurl

Might be OK, but it was a disk problem not a connection problem that caused it to be disabled.

Do you have another disk you could rebuild to?

Both emulated disks are mountable.

We need to fix why they became disabled before attempting rebuild.

SMART for both disks looks OK, previous syslog seems to indicate a problem communicating with the disks, connection or controller issue.

Looks like they are both on this controller:
08:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03) Subsystem: Broadcom / LSI 9211-8i [1000:3020] Kernel driver in use: mpt3sas Kernel modules: mpt3sasMake sure it has plenty of cooling.

Check connections, both ends, power and data, including splitters.

@MartinNr5
Do you have another copy of anything important and irreplaceable? Parity is not a substitute for backup.

I assume your check filesystem was on disk5, since you didn't mention emulated disk8 was also unmountable. I've seen worse, but I've also seen better. Not much you can do except FIX it and hope not too much ends up in lost+found. But let's leave that for later.

There may be other options with disabled/emulated/unmountable disk8, since we can try to repair the emulated disk, and compare the results to the physical disk.

Check filesystem on emulated disk8 from the webUI and post the results.

yes that will work

HDDs in array with 16TB parity.
SSDs in the array can only be written at parity speed and cannot be trimmed, so better if they are in pools outside the array.
2x2TB SSDs could be a mirror for your Docker/VM related shares - appdata, domains, system.
The 4 or the 8 should be more than enough for caching writes.

https://docs.unraid.net/unraid-os/download_list/

https://docs.unraid.net/unraid-os/system-administration/maintain-and-update/upgrading-unraid/#manual-downgrade-or-upgrade

Only user shares have the settings you are asking about. Any subfolder of a user share works the same as the settings for that user share.

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

That seems OK with certain assumptions. Diagnostics might help make better sense of things.

Go to User Shares page and click CLEAN UP button at bottom, it will delete any .cfg files for shares that don't exist.

You should also check that you don't have any files at the top level of array disks or pools. They would not be accessible from User Shares since the user shares are just the combined top level folders of array and pools.

Your appdata share has files on the array.

/data = /mnt/user/data/torrents

/data/torrents = /mnt/user/data/torrents/torrents

Are you using modular PSU cables that did not come with that PSU? There is no standard pinout for modular PSUs. Using modular PSU cables that weren't supplied with the PSU has fried many disks.

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

Your cache is NTFS.

I recommend you reformat cache to a filesystem with more history and support in Unraid, btrfs or ZFS.

df seems to indicate user shares are working, but apparently not completely. Some entries in syslog that might indicate corruption on ntfs cache, not sure about that. But that should go away if you reformat to another filesystem.

See if mover will still work to move all that to the array. Nothing can move open files. Disable Docker and VM Manager in Settings and leave them disabled until after you move things back to reformatted cache.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/cache-pools/#moving-files-between-a-pool-and-the-array

Some additions

Since you have Docker related shares - appdata, docker - on vm_pools, and VM vdisks also, might as well put libvirt.img (in VM Manager) there also and just not have the share named system.

isos doesn't have to be off the array since it is just used to install VMs, and can be unmounted from the VM if no longer needed. But it also doesn't take much space typically so it can be off the array if you want.

The only pool you have with redundancy is cells, which is small and I assume has some special purpose.

If you want appdata, docker, domains, isos to be protected, you need to make vm_pools redundant by adding another 64GB disk to make it a mirror. But I question whether 2x64GB mirror is large enough for the intended purpose of that pool. I recommend 2x256GB at least.

Those FAT-fs errors I posted from your logs means your flash drive is corrupt. Recreate from your backup.

It is a script. You can use the User Scripts plugin to manage scripts.

Here is a link directly to the script text:
https://github.com/SpaceinvaderOne/Unraid_check_docker_script/raw/refs/heads/main/Unraid_check_docker_script.sh

You can go directly to the correct support thread for this container by clicking its icon in your Unraid webUI and selecting Support

Disk15 is disabled now. When it couldn't be read Unraid tried to write its calculated data back to it and when that failed it was disabled.

Same thing happening with disk16, but since you have single parity and disk15 was already disabled, it couldn't be disabled.

So, instead of checking parity, now you need to rebuild disk15.

SMART for both disks looks OK and emulated disk15 is mounted.

Looks like these disks are on different controllers.

How are these disks powered? Ideally, no more than 4 drives per PSU cables. MOLEX - SATA splitters are better than SATA-SATA splitters.

I recommend dual parity with so many disks.

The few plugins you have are so out-of-date they can't be upgraded. You need to remove them and install the new versions.

3TB cache should be plenty for appdata and system shares. If you aren't using VMs you don't even need a domains share, system share should only be taking about 21GB, and if plex is your only container, appdata shouldn't be very large either.

And there will be plenty left over for caching user share writes, provided you have your user shares configured correctly.

The situation you describe is what the parity swap procedure is for.

Parity swap procedure isn't just about replacing parity. Some seem to think that because of the name, parity swap procedure is what they need to replace a parity disk.

What parity swap does, is copy parity to the new larger disk, then rebuild the failed data disk onto the old parity disk.

Parity swap is one of those phrases that automatically gets converted to a link into the documentation, so you can just follow the link for more details.

If you are ever unsure how to proceed in this or any other situation, please ask for help on the forum. Many ask for help after they have already made things worse.

Delete the oldest and move the most recent to cache if it isn't already, then delete the system folder from disk1.

Looks like docker.img was 50G, more than should really be needed if things were configured correctly, but it wasn't enough.

Then you changed it to 80G and it still wasn't enough.

The usual cause of filling docker.img is an application writing to a path that isn't mapped.

Delete and recreate as 50G. Don't reinstall Apache since that may be what pushed it over the edge.

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

Drive has disconnected.

Shutdown, check connections, restart, post new diagnostics