trurl

For future reference, you absolutely must not format a drive in the parity array if you want to keep its files. Format writes an empty filesystem to the disk. Unraid treats this write exactly as it does any other, by updating parity. So after formatting a drive in the parity array, parity agrees it has an empty filesystem, and rebuilding it will result in an empty filesystem. When you have an unmountable disk the correct thing to do is attempt to repair its filesystem. Ask for help before making a mistake.

I see you have luks:xfs as the default filesystem, so that is what "auto" means. If it doesn't give you the option to do the repair in the webUI you can probably do it from the command line, but I have no experience with encrypted drives so you should wait for someone else like @johnnie.black 😉

Still not possible with HDDs. Maybe you mean Mb/s?

That's good, but the most important share to set prefer is system, where docker.img is normally kept. If you have any of it on the array it can be a multi-step process to get it moved since mover can't move open files. If you need help with this post your diagnostics.

Not really a plex question and probably more suited to add on to one of your other threads you have started recently. Either way will work with plex and other things. Many people do separate shares because they want to manage them separately with the settings for each, such as Included Disks, Split Level, Minimum Free, etc. That is what I do.

This is not going to have any relevance. The only thing that happens when you try to use a data disk larger than parity is it won't let you start the array and it tells you why.

How much RAM do you have?

It is impossible to move from the faster cache to the slower array as fast as you can write to the faster cache no matter how often you run it. Running it more often might even make things worse. Mover is intended for idle time. Reconsider what you need to cache, or get a larger cache, or both. Done with what? I don't recommend caching any of the initial data load because cache won't have enough capacity and will just get in the way. People often don't assign parity until after the initial data load so writes will go faster without parity updates. Have you considered turbo write?

I doubt you're making as many as me haha

Aug 30 16:25:35 Tower kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 1b603ba7) Aug 30 16:25:35 Tower kernel: FAT-fs (sda1): Filesystem has been set read-only Aug 30 16:25:35 Tower kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 1b603ba7) Aug 30 16:25:35 Tower kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 2f309780) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Aug 30 16:25:35 Tower kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 2d75d3df) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Aug 30 16:25:35 Tower kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start 682728bd) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Aug 30 16:25:35 Tower kernel: FAT-fs (sda1): error, fat_get_cluster: invalid start cluster (i_pos 0, start c24995fc) Put flash drive in your PC and let it checkdisk. While there make a backup. Try again. Be sure to boot from a USB2 port.

Anything using the array disks during parity check or parity sync or data disk rebuild (basically all the large parity operations) will slow down these parity operations and also slow down those things using the disks, since they are competing for the same disks and since they will likely have to take turns seeking different sectors of the disks than the one the other process is accessing. It won't break anything though. I sometimes use the array briefly and occasionally during parity checks, but not for large transfers.

I don't know about that software, but Windows does not natively support any of the filesystems used by Unraid. The software often recommended is UFS Explorer. You might try repairing the disks filesystem as an Unassigned Device in Unraid. https://wiki.unraid.net/Check_Disk_Filesystems#Drives_formatted_with_XFS Be sure to note this part in the Additional Comments of that wiki:

If you were trying to demonstrate how many slots you allow for cache that screenshot doesn't do it.

At this point my recommendation is to disable docker service (Settings-Docker) and quit using the server until you successfully rebuild parity (your array is currently unprotected). Then before enabling docker again we can work on this To rebuild to the same disk (whether parity or data) Stop array Unassign disabled disk Start array with disabled disk unassigned Stop array Reassign disabled disk Start array to begin rebuild

Seems like a Flash problem. Go to Tools-Dagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Don't hesitate to ask for help. What really makes me sick is someone asking for help too late and they have already screwed it up on their own.

I really wish you had asked for help very early on. Since disk6 was disabled, it was being emulated by all the other disks from the parity calculation. But some of those disks were having connection issues. So it is possible disk6 wasn't really corrupt, but the emulation of disk6 was corrupted by the bad connections on the other disks. In any case, instead of formatting the disk, the correct thing to do would have been to repair its filesystem. Here is another recent thread that you may find educational:

Did you ever format the disks in the array? You have to let Unraid format a disk before it will have a filesystem.

Also, have you tried reducing the number of disks allowed in the pool to only one? (stop the array to see what I mean)

What is the filesystem of cache on that other server?

You apparently misread or misunderstood. This statement came after several others in that post and in this thread discussing Unraid User Shares. User Shares are what you share on the network. I don't recommend sharing the actual disks that Unraid uses for those User Shares.

Laptop isn't really a good platform for Unraid anyway. What do you plan to do with Unraid?

Accessing Unraid shares over the network isn't really any different than accessing shares on any other computer on the network. Have you ever worked with networked computers before? What exactly about the normal way you access Unraid shares over the network do you want an alternative to?

Like the rest of the Unraid OS, the syslog is in RAM, so it starts over when you reboot. But there was enough after the reboot for me to see some things and answer some questions. ata1 is the connection to parity, ata2 is the connection to disk2 Aug 29 13:38:24 Tower kernel: ata1.00: ATA-9: WDC WD100EMAZ-00WJTA0, JEGL12UN, 83.H0A83, max UDMA/133 ... Aug 29 13:38:24 Tower kernel: ata2.00: ATA-9: WDC WD80EMAZ-00WJTA0, 7HKGB64F, 83.H0A83, max UDMA/133 ... Aug 29 13:38:33 Tower kernel: md: import disk0: (sdb) WDC_WD100EMAZ-00WJTA0_JEGL12UN size: 9766436812 ... Aug 29 13:38:33 Tower kernel: md: import disk2: (sdc) WDC_WD80EMAZ-00WJTA0_7HKGB64F size: 7814026532 (emulated) disk6 was unmountable Aug 29 13:38:43 Tower emhttpd: shcmd (60): mkdir -p /mnt/disk6 Aug 29 13:38:43 Tower emhttpd: shcmd (61): mount -t xfs -o noatime,nodiratime /dev/md6 /mnt/disk6 Aug 29 13:38:43 Tower kernel: XFS (md6): Mounting V5 Filesystem Aug 29 13:38:43 Tower kernel: XFS (md6): Corruption warning: Metadata has LSN (1:7162) ahead of current LSN (1:843). Please unmount and run xfs_repair (>= v4.3) to resolve. ... Aug 29 13:38:44 Tower emhttpd: shcmd (62): umount /mnt/disk6 Aug 29 13:38:44 Tower root: umount: /mnt/disk6: not mounted. Aug 29 13:38:44 Tower emhttpd: shcmd (62): exit status: 32 Aug 29 13:38:44 Tower emhttpd: shcmd (63): rmdir /mnt/disk6 rebuild of disk6 started but parity and disk2 were disconnected. (SMART for disk2 also OK) Aug 29 13:39:18 Tower kernel: ata1.00: exception Emask 0x10 SAct 0x100000 SErr 0x4890000 action 0xe frozen ... Aug 29 13:39:18 Tower kernel: ata1: hard resetting link ... Aug 29 13:39:18 Tower kernel: ata2: hard resetting link rebuild aborted and you formatted disk6 Aug 29 13:39:45 Tower kernel: md: recovery thread: exit status: -4 Aug 29 13:39:46 Tower emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Aug 29 13:39:46 Tower emhttpd: shcmd (107): /sbin/wipefs -a /dev/md6 You may recall I said When you format a disk in the parity array, Unraid treats this exactly like it does any other write operation. It updates parity. After formatting a disk in the parity array, parity agrees that the disk has an empty filesystem. So rebuilding a disk that has been formatted will result in an empty filesystem. Then the answer to one of your earlier questions is NO. Do you have backups? I can tell you how to rebuild parity but the connection issues you have been having will probably make this a problem.