trurl

There are other good reasons for IT mode. Currently there aren't even any SMART reports for your disks, for example.

https://wiki.unraid.net/Crossflashing_Controllers

You might be able to do that, but it's not necessary to accomplish what you want. The other server must also run apcupsd, and you configure apcupsd on that other server to monitor the UPS status over the network to the apcupsd on the Unraid server, and configure apcupsd on that other server to shutdown based on that status it gets over the network. Or, you could do it the other way and have USB cable on the other server and have Unraid monitor it over the network. I do it like this except my other computer is running apcupsd on Windows instead of linux. Obviously the network must be on UPS for this to work.

reformatting is probably the best thing anyway so you can take advantage of the new alignment for SSDs. Be sure to read earlier in the thread about that.

https://wiki.unraid.net/The_parity_swap_procedure

Will Unraid not let you start them both at the same time, or does it let you start them both but then one of them doesn't work?

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Other things besides bad cables can cause connection problems. Probably more common than bad cables is simply not having a good connection between the cable and drive or cable and port. Make sure there is no tension on the cable that might pull on the connection. Also, don't bundle SATA cables, they are not shielded and bundling them together can cause crosstalk between them.

Unraid is just reporting what the drive SMART reports. CRC errors are connection problems, these are recorded by the drive firmware and returned by the drive in the SMART report, just like all the other SMART attributes. You can acknowledge the current count by clicking on the SMART warning on the Dashboard. It will warn again if the count increases. If they do continue to increase try to fix the connection problem.

On the Dashboard page under Docker Containers, there is a slider to show All Apps or Started Only.

Some people have used UFS Explorer to recover data. Might be easier and cheaper to just go to your old disks.

A better way to say it is you shouldn't mix disks and user shares when copying / moving. If you are not sharing disks on the network then you don't have disk shares, but you still have disks, If you work directly with the disks on the server, such as with krusader / mc / command line, and you move or copy from disks to user shares or from user shares to disks, you can wind up with empty files. This is because linux doesn't know a disk file might be the exact same file as a user share file if the paths work out that way. So it tries to write what it needs to read, starting with creating the empty file to be written into.

Another way to say the same thing is no data drive can be larger than the smallest parity drive. Each parity must have bits to cover each bit of data. One of those parity disks wouldn't have parity for any disks larger than 8TB, so not dual parity and not allowed. Have I given you the link to the wiki on parity? https://wiki.unraid.net/UnRAID_6/Overview#Parity-Protected_Array Parity is not complicated. Parity is a concept often used in computers and communication. It is just an extra bit that allows a missing bit to be calculated from all the other bits. Same concept wherever it is used, just different implementation details. Parity2 (Q) is a different algorithm than Parity (P) so they can be independent, but still basically the same concept.

Another possible approach would be to not delete your docker.img. Just set appdata, domains, system to cache-prefer, disable dockers and VMs while you move them, and run mover. Docker.img is wasting a lot of space, but looks like it must already be on cache based on your screenshots, so docker.img wouldn't get moved anyway. I may not be on the internet for most of the next 2 days, but will check in occasionally.

If the files were originally on the disabled disk, but the disk got disabled, then Unraid is no longer accessing whatever is on the disk. It is only accessing the emulated disk. You repaired the emulated disk because it was corrupt. The result of the repair is the lost+found you see on the emulated disk. Possibly the filesystem on the physical disk was really corrupt before it became disabled, and at the point the disk was disabled, the corruption on the emulated disk was due to the corruption already on the physical disk. Possibly it was only the emulated disk that was corrupt because one of the other disks involved in the emulation is returning bad data. Possibly both.

Don't know what you mean by corrupted here. Each disk in the parity array is an independent filesystem. Individual disks can have filesystem corruption, but the array doesn't have anything to corrupt separately from the individual disks. There isn't any "meta of the array". WIth an emulated disk, the parity calculation gets the data for the disk by reading all other disks, but there isn't anything "meta" about that. Since you repaired the emulated disk, the lost+found are on the emulated disk. We don't know what might be the contents of the physical disk since you can't access the physical disabled disk without mounting it outside the array. I think it extremely unlikely if not impossible for VMs and dockers to cause disabled disks. Unraid disables a disk simply because a write to it fails and for no other reason. You almost certainly have unresolved hardware issues.

cables and ports are unrelated to my question since Unraid keeps track of disk assignments by drive serial number. I was asking about the disk assignments and whether or not you may have assigned them incorrectly. Accidentally assigning a data disk to the parity slot will overwrite that data with parity. Possibly all the missing data was on disk1, for example, and you accidentally assigned that disk as parity.

If it's mountable in UD you should see a Mount button and it should show the filesystem under FS. UD does support ext4 but apparently nothing but your pi recognizes that disk as ext4. What OS is your pi?

No. Basically, docker.img is just the executables for the dockers containers. These are easily downloaded again. Deleting docker.img will delete all of your dockers. But their working storage will still be in appdata, for example plex metadata and any settings made within each application. And the settings used to create each docker, such as the mappings, etc. are in templates on flash. The Previous Apps feature on the Apps page will use those templates to reinstall all your dockers exactly as they were. It's best to recreate custom docker networks before reinstalling the containers that use them so they will be able to use those custom networks when they start. Might be useful to have a screenshot of Dockers page to remember which custom networks are needed by each. My setup is probably simpler than yours. I just have one custom network for those things that go through SWAG (letsencrypt) and DuckDNS.

Lets go ahead with getting appdata, domains, system moved to cache. I'm going to bed now but I will go ahead and tell you what I have in mind for next. You can go ahead with it if you want or you can wait till tomorrow if you don't want to go without dockers or VMs until then. Set appdata, domains, system shares to cache-prefer. Go to Settings - VM Manager and disable VMs. Leave them disabled Go to Settings - Docker and disable Dockers. On that same page, delete docker.img. Change its size to 20G. Leave them disabled Run mover and wait for it to complete then post new diagnostics.

Looks like DVR TV Shows has all its files on cache. Go to Shares - User Shares, click Compute All. Wait for the result. If it doesn't appear after a few minutes, refresh the page. Then post a screenshot of the results.

Are you sure something doesn't have those files open? Go to Settings - Docker and disable dockers, then try to move them again.

Since the docker service failed to start you can't ask docker what custom networks you had. If you were following SpaceInvader videos for letsencrypt for example, then you probably had docker network create proxynet Go to Settings - Docker, disable and delete docker.img But, your system share, where docker.img is configured to live, is on the array and it is set to cache-yes instead of prefer as it should be. Are you sure filling cache is what corrupted it? Doesn't seem likely since it isn't on cache or configured to be on cache. Possibly you filled docker.img instead. Have you had problems filling it? I see you have allocated 30G but 20G is often much more than enough unless you have some app misconfigured so it is writing into the image. You should get system share all on cache and set to stay on cache before recreating docker.img, recreating custom docker networks, and reinstalling your dockers from Apps - Previous Apps. Do you actually run any VMs? Those would be using libvirt.img which is also in system and on the array. You need to set system to cache-prefer so mover can move it to cache, but since mover can't move open files you will have to disable VM Manager in addition to disabling Docker to get system share moved. appdata is all on cache so that much is good. You can decide if you want domains share on array like you have it now, but be aware that VMs accessing that share (vdisks) will have performance impacted by parity and will keep array disks spunup. Often domains can also live completely on cache, since the VM OS vdisks may be all you need and VMs can access additional Unraid storage over the virtual network. Looks like cache has plenty of capacity for all this while also caching user share writes.

There is no striping in Unraid, each disk is an independent filesystem. This fact is what allows you to mix different sized disks in the array.