Squid

On the schedule you've set in mover settinga

The entry in the unRaid FAQ dealing with csrf has a link explaining what they are and the security implications

Its logged in the syslog

muscle memory is a hard thing to overcome ?

Yes technically powerdown is deprecated. However, the day that it actually stops working will not be a happy day for me, and an immediate PR will be put it.

Enable log when not moving, and you'll see what's happening

All that's needed is the second line. Don't know why you would want to stop docker, restart it, then reboot.

and no. That's the source (which the plugin already knows about) The plugin is asking you for the destination

Why would you want to backup your flash drive to the flash drive?

Reboot the server. If that doesn't bring back the apps (and the icon in the plugins section), then delete /boot/config/plugins/community.applications.plg Reboot, then reinstall CA

Meaningless what top / dashboard reports without also knowing what task manager itself is reporting.

+1

Reading between the lines of this https://lime-technology.com/forums/topic/33415-stopping-docker-img-causes-array-wide-spin-up/?tab=comments#comment-656791 A sync is issued when docker stops which would explain what you're seeing

Try and see.

Yup. Probably crond would log it, and an email will be sent out to whatever email address has been set up in notifications about the crond failure. Anything that cron as installed on unRaid supports can be used. Only thing off of the top of my head is that slackware does NOT support day of weeks spelled out (SAT / SUN eg) whereas the online documents say you can. This includes piping the cron expression to another bash command to further refine it

There's a setting on under what circumstances to send notifications.

Assuming FCP isn't miles out of date, that means that when the tests ran (10 minutes after the Array Started event), /mnt/user didn't exist anymore and the state according to emhttp was not "STARTED"

Don't do that... If you run the tool against all drives / all shares, the Appdata share gets changed which may or may not have adverse effects on the apps. Use Tools - Docker Safe New Permissions which won't touch anything in appdata.

Try making the window larger

You don't have a data mapped to the app with the exact same path mappings as your download client

You have a browser tab open to the dashboard from before the reboot. Either close it or refresh it.

Why not just make a backup / copy of the existing appdata folder for safety sake, then install the lsio version and point it at the existing appdata folder and see what happens. Odds on there will be no problems

Docker containers start first, then VM's While the startup selection in the docker page is a plus, considering that a startup order of A,B,C vs a startup order of B,C,A doesn't make a ton of difference since as soon as container B is started, the next in the order is started immediately (the faster the cache drive, the more this is exacerbated all else being equal) . But, B may still be firing up, so any dependencies that A for instance has on B or C may still not be met. While the docker start manager came out before unRaid's UI supported a startup order, and now they do somewhat overlap, it still has its place as it lets containers either have a set delay before starting, or check to see if such and such port responds on such and such IP before starting. (useful for dependencies against a VM)

That'll work. Every hour it checks. If the cache drive is 80%+ full, it'll move. You don't have a force move cron set, so mover will only ever execute when the drive is at that threshhold BTW, you should disable Mover logging. No real purpose to it (MoverShedule settings, not Mover Tuning Settings)

The driver is on the virtio ISO disk. You need to attach that to the VM template