Squid

IDK There's no corresponding errors in the syslog when that no medium found error happened. I'd simply reboot and go from there. Oh, and turn off debugging on the auto turbo mode plugin

Perfectly normal and expected. The image the pop up is talking about is the file(s) within the docker.img, not the appdata folder. To remove appdata (effectively start the app over again from scratch) you either remove manually or use a tool like cleanup appdata Implies that something went seriously wrong on your server and the user shares were not available. Diagnostics would have helped here. /usr/bin/docker isn't a folder available to view over the network. I think you're confusing with /mnt/user/... /config mappings are hidden by default. Hit "Show More Settings" Possible, but unlikely that its directly related to Plex, unless you have other underlying problems with your system.

Sure. Except that user scripts will run a script that has CRLF line endings by design, but the scripts accepted by Backup have to be standard LF only

Run in addition to the backup Stop scripts run before the containers are stopped. Start scripts are run after the containers are restarted

on the todo list

It works fine with only one backup. What you may be seeing is that with the unRaid GUI as a whole, all the separate tabs within any page are actually all rendered at the same time. So you went and did a backup, then immediately went to Restore. Since the restore page was rendered at the same time as when you loaded the backup page, it showed no sets available (because you hadn't already created one)

CA_Backup.tar

Most causes of docker.img getting that big is either out of control logging by the apps downloading directly into the image Both circumstances are covered in the docker FAQ

It means that there's either no tar inside the folder, or on the backup settings the destination is wrong.

Quite often the permissions within any particular application's appdata is not compatible with how unRaid deals with permissions and what doing things over the network expect. You will have no problems however if you copy via the command line.

Post your diagnostics or syslog

Fixed next release. Only a warning. Doesn't affect any test. Cause is that you've never gone to Settings - Share Settings and made a change. Nothing to worry about on your end.

Install today's update for FCP and rerun. PITA for me to check for 6.3.5 compatibility. I maintain 2 server's: One with the "next" branch (ie: any RC), and one with the latest stable, so a minor difference between 6.3.5 and 6.5.0 slipped through.

I don't use binhex, but Radarr / Sonarr in settings (advanced shown) media management you can set the permissions of the files / folders. I set each to 0777 with no problems on R/W

Can you update to today's release and try it again. Thx

/tmp/fix.common.problems/extendedLog But you have to have a ton of problems for it to crash the browser. Give it a couple of minutes to figure it out and render the display.

Try switching the VM to only use a single core, and start in safe mode (Windows 10 IIRC after 3 times failing to boot will automatically offer you that option) You can see why windows blue screened via it's event viewer (start, type in event) My causes of BSOD's are bad memory. Add a VM to the mix, and you also need to make sure you're running the latest virtio drivers and bios versions for your motherboard

Because that update doesn't have this fix. Tomorrow's will. I guess I could pump it out today, but every time I start doing releases of 15a, 15b, etc @CHBMB makes fun of me so I only do them nowadays when absolutely necessary.

Thanks. There'll be an update tomorrow that will fix this false positive

Figures. I thought you may be a no-show so I pumped out an update. Oh well... Post me the output of fdisk -l /dev/nvme0n1

zip them up and post or pm them to me

Fixed.

Doesn't happen for me. Looks to me like you have a corrupted XML file on your flash drive (/boot/config/plugins/dockerMan/templates-user)

Plugins due to their nature of always running as root have a very high risk factor. Without a support commitment from whomever takes over, the general recommendation (admittedly not universal) is to not install them. But, I am aware of two separate discussions regarding new projects to replace this. Whether or not something comes of it remains to be seen. Not a fork. Rather a hack which has the net result of technically installing an incorrect version of a support file with possible unknown consequences. Copyright 2015-2017, gfjardim

Do you have the MD5 entry on the <File> for the txz. sorry at work. I'm assuming that a fresh install works for @CHBMB