trurl

Unrelated to this problem, but your appdata and system shares have files on the array. Also, you have a large number of small disks. Fewer larger disks would be more troublefree and efficient.

But you don't want to run that long on battery. You should set it up or even less.

Did you try booting from a USB2 port AFTER to creating it again? Are you using a USB2 flash drive? What brand? Have you tried the manual method of creating the boot flash? See here: https://wiki.unraid.net/UnRAID_6/Getting_Started#Manual_Method_.28Legacy.29 and here: https://forums.unraid.net/topic/85785-server-wont-boot-panic/?do=findComment&comment=795122

Just thought I would add some links to recent threads where others are having similar problems. https://forums.unraid.net/topic/86638-libvirt-service-failed-to-start-unraid-680 https://forums.unraid.net/topic/86545-vm-manager-and-all-vms-are-blank-disappeared https://forums.unraid.net/topic/86730-help-to-create-new-path-in-vm-manager https://forums.unraid.net/topic/86699-libvirt-service-failed-to-start

You probably have some misconceptions about the USB Flash drive. Think of it as firmware except easier to work with and unbrickable. The OS is loaded into RAM from the archive on Flash at boot and runs completely in RAM. Flash is also used to record Settings you make in the webUI. Otherwise Flash isn't accessed much.

Make sure you are booting from USB2 port

Yes, change docker image size to 20GB, then enable will recreate it on cache. Then Previous Apps on the Apps page will use the settings you had before to add your dockers again.

That's really too large to post even zipped I guess. Probably a lot of the same stuff over and over anyway. Might be better to start over by rebooting, and then later get diagnostics so we can get the new stuff from docker.log the usual way.

docker.log is all that gets into diagnostics so you would have to post that older docker.log.1

Looks like the one on disk3 has the newer timestamp. See if you can delete one of them in VM Manager Settings, and then delete the other manually and start over.

What is your transcode mapped to?

Unraid 6.8 has WireGuard VPN builtin. If you want to access your server from outside your local network, VPN is essential.

Unlikely to be a bug since others aren't reporting it. And you haven't told us much to base any opinion on. If you had diagnostics, or even better, diagnostics plus syslogs that covered the occurrence of these issues, then we might have something to go on. https://forums.unraid.net/topic/37579-need-help-read-me-first/ https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601 Also, you have posted in a thread that is already marked solved. It is essentially dead so I guess we won't consider it hijacking, but starting a new thread might have been better.

It has been explained pretty well already, and I think you probably do understand, but the way I prefer to say it is parity PLUS all remaining drives allows the data for a missing drive to be calculated. That one parity drive doesn't preserve anything by itself.

If this is similar to other recent reports, you need to stop the array, then try to work with the VM Manager Settings while the array is stopped.

Probably that message is telling you exactly what the problem is. Post the exact message text.

The main thing is to not assign any data disk to a parity slot. So if you don't know which disk should be parity, then assign all disks as data and none as parity. Parity will be the disk that is unmountable, since it doesn't have a filesystem to mount. If you have single parity then you would have 1 unmountable, if dual parity then 2 would be unmountable. Regardless, don't agree to format anything.

Yes, libvirt image is a duplicate. I think the one on cache is probably the current one. What do you get from the command line with these: ls -lah /mnt/cache/system/libvirt ls -lah /mnt/disk3/system/libvirt

Must be a duplicate on disk3. Go to Settings - Scheduler Settings - Mover Schedule and enable Mover Logging. Then run Mover again and post a syslog.

@Shinta0Saint @Shinta0saint1 Have you created 2 accounts?

system share still has files on the array. Go to Settings - VM Manager, disable, then go to Main - Array Operation and Move Now. When it completes post new diagnostic.

Since it isn't happening to everyone else it must be something specific to your systems. You haven't told us much about them though.

After you disable and delete the docker image, do not enable it again. You can change the size later when you enable it, but for now I want to see if any of your system share is still on the array. What often happens is someone will enable docker and/or VM service before installing cache, so those images get created on the array. And mover can't move open files so they get stuck there.

Your docker image doesn't seem to be mounted for some reason. It is far larger than necessary anyway. Why have you set it to 70G? Have you had problems filling it. 20G should be more than enough and making it larger will not help anything. And your system share has files on the array instead of all on cache like it should. libvirt image isn't mounted either. Do you have any VMs? Go to Settings - Docker, disable and delete docker image. Then post a new diagnostic.

Are you sure it is plex to blame? I see plex getting killed in your syslog, but that might just be due to OOM deciding to kill plex because something else has filled RAM. I admit I'm not entirely sure how to interpret those parts of your syslog, but I am using LSIO plex and not having this issue.