trurl

Single parity allows one missing disk. Size of disks or amount of data doesn't matter. Parity doesn't even know anything about the data. The parity calculation uses parity PLUS ALL remaining disks to calculate the bits for the missing disk. Since all disks are needed to rebuild a missing disk it's important that all disks are reliable. Just a bunch of old disks you happen to have may not be the best way. And fewer larger disks are better than more smaller disks since each additional disk is an additional point of failure.

There isn't much to worry about as far as safety is concerned since you already have no redundancy. To copy the data from an array disk to that "smaller" disk will require a few steps with a (not very big) learning curve. We can lead you through that if you want. Simplest is going to be Unassigned Devices and UD+ to format that disk so it can be used in the array, then Midnight Commander to copy the data to the UD, then New Config to get it into the array and parity built on the other disk. I say simplest because Midnight Commander is builtin, but many prefer to use Krusader docker for the copy part of that so that would be another thing to setup. You might google Midnight Commander to see if that is something you feel you can use. Even simpler would be to do the copy over the network by making a round trip from the server to your PC and then back again but that would be somewhat slower. Or, if money is not a huge issue, you could just get an "internal" HDD for parity, and add that shucked drive to a new data slot.

I think this container pulls the latest plex when it starts so you don't have to wait on an update to this docker, just restart it. Worked for me a few days ago.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

The syslog included in Diagnostics, and the syslog you get from the webUI, are only since reboot. If you have logs from Syslog Server you will have to get them from wherever you had it set to store them, zip them up, and attach to your NEXT post.

If you are talking about New Config, nothing going on. All it means is you can assign any disks any way you want, and then optionally (and by default) rebuild parity. Nothing happens to any of your other settings, and nothing happens to your data unless

What exactly do you mean by jbod in this context? single or raid0 or what? Are the drives the same size?

What happens with Krusader, rsync, many other applications is this. It creates all the folders before it begins to copy the files. Since the disk has plenty of room for the empty folders, they all get created on that one disk. Then the files get copied into those already created folders. So, you have to do the transfer in separate smaller batches.

Bring us all up to date on your docker run command and plex transcode directory.

Why do you have 50G allocated for docker image? Have you had problems filling it? Also Fix Common Problems says a number of your dockers are missing templates. Any idea what that is about?

Do you mean you plugged in the parity2 disk? If so you probably disturbed the connections to parity1. Those are the same diagnostics you posted earlier in the thread two days ago.

This is correct. Why would you think otherwise?

That would be because the mapping for /boot doesn't make any sense. Change it to /FLASH, not \FLASH. \ is an escape character in Linux, not a path separator as it is in DOS/Windows. After fixing that mapping, reboot and then see if you continue to fill rootfs.

Any idea what is filling your syslog with these? Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [HomeServer.local#011IN#011AAAA fe80::85f:1cff:feb1:cca5 ; ttl=120] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [HomeServer.local#011IN#011A 10.242.170.2 ; ttl=120] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [_device-info._tcp.local#011IN#011PTR HomeServer._device-info._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [HomeServer._device-info._tcp.local#011IN#011TXT "model=Xserve" ; ttl=4500] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [HomeServer._device-info._tcp.local#011IN#011SRV 0 0 0 HomeServer.local ; ttl=120] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [_sftp-ssh._tcp.local#011IN#011PTR HomeServer._sftp-ssh._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [HomeServer._sftp-ssh._tcp.local#011IN#011TXT ; ttl=4500] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [HomeServer._sftp-ssh._tcp.local#011IN#011SRV 0 0 22 HomeServer.local ; ttl=120] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [_ssh._tcp.local#011IN#011PTR HomeServer._ssh._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping. Jan 28 21:14:25 HomeServer avahi-daemon[8523]: Record [HomeServer._ssh._tcp.local#011IN#011TXT ; ttl=4500] not fitting in legacy unicast packet, dropping. Difficult to wade through all that. Since you have dual parity your data is probably going to be OK. The disabled disks are not reporting SMART. Most likely a connection issue. Check all connections, both ends, SATA and power, including any power splitters. Then reboot and post new diagnostics.

Diagnostics only include syslog since last boot. If it was setup then it will have saved syslog from before boot. You should attach that to your NEXT post so we can maybe see why the disks were disabled.

You have replied to a thread that is over a year old. What version of Unraid are you using?

SMART for those disabled disks looks OK. Since you rebooted I can't tell from syslog what happened. Do you have Syslog Server setup? https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601 You have more disks than I care to examine. Do any of your disks have SMART warnings on the Dashboard?

No, I don't mean does Krusader work. I mean, does that mapping for /boot work? Can you actually get to the contents of your flash drive in Krusader?

Your Krusader mapping for /boot doesn't look right to me. Does it work?

Which dockers do you have?

Not sure what you mean by this. If you are talking about having their files stored directly on the server instead of having them stored on their computer and then backed up to the server, then obviously that is not a backup plan. Post your docker run command for plex as explained at the first link in the Docker FAQ pinned near the top of the Docker Engine subforum.

According to the ASUS website it does have 2.0 ports on board. There are 2 headers listed as #14 in the diagram on page 1-2 of the manual. Don't know if that would help this particular problem or not, but it might help future problems if you do get it to boot. Try this manual method for preparing flash: https://forums.unraid.net/topic/85785-server-wont-boot-panic/?do=findComment&comment=795122

You have to delete all folders and files in the share, then you can delete the share from the Unraid webUI by going to the settings page for that share.