Squid

If that was known, then it wouldn't be an issue

Unassigned devices plugin

This https://forums.unraid.net/topic/36057-noobie-docker-setup-guide/#comment-345882 in conjunction with https://github.com/FalconChristmas/fpp/blob/master/Docker/Dockerfile

Enable the syslog server in unRaid to mirror to flash (Settings - syslog server). If it crashes again, post the file created, your diagnostics, and what's detailed here: https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

Just FYI, if you are having problems, then you should set the mover tuning plugin's parameters back to "normal" Otherwise, it introduces another variable for @limetech to calculate, and he may/may not be aware of the plugin, so the disk IO priority option he may not have a clue about what you're talking about.

Have you run a memtest yet? Sent from my NSA monitored device

Intermittent issue for some people where GUI works for them, but regular boot doesn't and vice versa. Why not just use the regular boot mode and control the GUI via a browser.

Can you post your diagnostics. That should work

You should probably post in the relevant support thread for the app you're running (you can get it via the context menu on the docker tab) with your docker run command and any relevant log from Plex as it's unlikely to be directly related to the OS itself

NFS or SMB? There's a field right there when you add SMB share for username / password. I don't use NFS so can't help you there.

If you edit the VM and switch to xml view, you can change the boot order <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Windows 10/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Win10_1903_V1_Norwegian_x64.iso'/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.160-1.iso'/> <target dev='hdb' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> Change the boot order for the cdrom to be 1, and the vdisk to be 2 But, as to the boot loop, try only setting the VM to use a single core and see if that makes a difference temporarily

Can you post a screenshot of your schedule settings, and the output of cat /etc/cron.d/root

unRaid doesn't have auto update. It does have an update all button which as it states updates all containers that have an update available. There is an auto update plugin available which does indeed allow you to cherry pick which apps you want it to automatically update for you.

Ultimately at a reboot, all plugins install before the array is online, so it doesn't matter one way or another at all.

You could try switching to nzbget (it's more efficient) but, your issue sounds like a drive hs to spin up to store the downloads. This will tend to pause all active transfers with most controllers

delete /config/plugins/customtab/* on the flash drive and try again.

Side Note: It can't be included due to it using a graphing library that is incompatible with unRaid's licence (or more to the point, it can't be included without significantly raising the cost of your licence)

IDK

Assuming Windows VM, without setting the vdisk up as a scsi drive (as detailed in the thread), the vdisk will always grow to it's maximum size, just from windows creating and then deleting temporary files. The size of the vdisk is the total of all all the files currently on the vdisk plus the size of every file ever created on the vdisk up to a maximum of the vdisk size. IE: No matter what you do it will always eventually (usually pretty quickly) hit the size of the vdisk you've set. The link describes how to set up the template and windows so that the vdisk will grow and shrink accordingly.

Full Probably the 230GB is actually GiB whereas the 240GB is actually GB, hence the problem as 230 GiB == 246GB Not quite sure how to properly recover here, but for next time, you can do this to keep the vdisk as small as possible https://forums.unraid.net/topic/51703-vm-faq/#comment-557606

This. The diskspeed app will show the curve for each individual drive

You've got a bad connection to one of your drives. From the Main tab, click on each drive's little "drive icon" to bring up the log for the drive, and it'll be pretty obvious which drive is causing the issue.

You're going to have to reboot to regain any measure of control. After that, post a picture of your docker tab

Then I would still go with the vdisk size is larger than the ssd. How much free space is available on that SSD?

Another possibility is that your VM is going to sleep