Squid

Have you run "make_bootable.bat" as administrator?

Usually (but not always) that would mean that in the BIOS boot order it's attempting to boot from a hard drive first. Anything but the flash drive.

Would probably be good to post your diagnostics when this happens and also the xml template you're attempting to add (/config/plugins/dockerMan/templates-user/)

Irregardless of the use cache setting, writes to user shares will tend to spin up disks, as the system has to check to see if the folder and file being written to already exists on the array so it can overwrite if necessary. Installing dynamix cache dirs will mostly alleviate this. As to it rewriting vs simply moving, this is because sonarr is moving the file from (as far as its concerned) /downloads to /media. Since those are two different mount points, any OS will do a copy / delete operation instead of a simple rename to the new folder. How to alleviate this is to instead of passing through /downloads and /media is to pass /mnt mapped to /mnt to all the apps involved and then reference within each app's settings (sonarr and your dl client) /mnt/user/...

Assuming qbittorrent Default Credentials Credential Default Value WebUI Username admin WebUI Password adminadmin

After running it, doesn't the banner appear at the top from unRaid stating a new version is available, with a click to download link?

-reserved-

CA Mover Tuning A simple little plugin (mainly created for my own purposes) that will let you fine tune the operation of the mover script On scheduled runs of mover, only actually move file(s) if the the cache drive is getting full (selectable threshold) On scheduled runs of mover, optionally don't move if a parity check / rebuild is already in progress Ability to completely disable the scheduled runs of mover if so desired (Not sure if there's much demand for this) Manually executed runs of mover ("Move Now" button) can either follow the rules for schedules, or always move all files After installation (any guesses as to how to install the plugin?), the default settings are set so that there is no difference as to how unRaid normally handles things. You'll find it's settings within Settings - Scheduler

It's not mappings per se. Rather its the settings inside the containers. See this as an example of how things can go wrong with a simple typo https://lime-technology.com/forums/topic/40783-issues-with-either-unraid-or-docker/?tab=comments#comment-399898 Or for a more common mistake: https://lime-technology.com/forums/topic/40815-community-applications-plugin-broke/?page=2&tab=comments#comment-400994

Have you forwarded the appropriate port (32400) on the router?

Great little app. It would be sweet though if the two halves of the screen were able to scroll separately from each other (so that when I have to scroll down on the left to find a drive and click on it to see it's benchmark, the display doesn't scroll up to the top)

Doesn't that also imply that non-surveillance drives will drop frames (ie: data) on a continual stream of writes? If that's the case, then I'm switching over to be 100% surveillance drives if they're the only ones that won't lose data when I'm writing to them....

Switched from USB passthrough to using this, as my coffee lake system basically has all the USB controllers as one and can't be split apart, and I can't be bothered right now to pick up an additional USB controller But, question though. Is it possible to have the "last state" of hot-plugged devices through this plugin carried over to the next reboot of unRaid without modifying the XML?

At least that's a simple XML edit vs what we've had to do prior

To elaborate Jon, it is *very* common to utilize a vdisk to be set up as "scsi" so that the vdisk will shrink in size (instead of always growing), and to also take advantage of trim when the vdisk is hosted on an SSD. Since the VM manager doesn't support scsi (and in conjunction with that discard=''unmap"), any changes to the template results in you having to re-edit the xml by hand to reset the drive / controller back to be scsi.

You pretty much have to be on dial-up for the appfeed to ever suffer from a download timeout. But, after 45 seconds trying to get the appfeed it's going to assume that it's not going to be able to get it, and the ask you to switch to legacy mode. Legacy mode may take a couple of minutes on a very slow download speed, but it will never time issue an nginx timeout. Rather it spends 45 seconds trying to download each repository. If that repository times out, then the apps available within it will not be available. CA will automatically switch back to appfeed mode when an update is available from the appfeed. If you want to switch it back before that, then you can just press appFeed Mode in the top right. CA never actually checks for updates for any installed container or plugin. Rather it utilizes what dynamix says is available (if you have dynamix in its Notification settings checking for updates on a schedule). For why CA timed out, is there something logged at that time. If there is (nginx timeout), then this is a problem some users have (not me) on 6.5. You're best off installing 6.5.1-rc3+ to alleviate that.

First and foremost, you've got bigger fish to fry. You're actively being hacked. syslogs are nothing but attempts to log in. Apr 3 04:41:15 Tower sshd[20618]: Failed password for root from 58.242.83.42 port 10376 ssh2 I suggest you close the ports you're not requiring, and take the server out of your DMZ, and then worry about other stuff.

You uninstall the advanced buttons plugin. It's incompatible

Give yourself credit.. You are being "that guy". Actually you found an issue that's been there for quite awhile where no inline variable would work on a custom scheduled script. Check for updates. (Also just to note, I can't detect when a check / rebuild is actually started. Only once it gets rolling. IE: during disk spinups etc the script will still run.

Never in my wildest dreams did I think that people were going to have problems with Legacy Mode downloads timing out on 6.4+ (I usually go by the assumption that everyone's hardware and internet connection is better than mine) Nevertheless, the rather extended outage by Digital Ocean accelerated the need to slightly revamp how Legacy Mode downloads are handled. There is now basically zero chance that niginx (unRaid) will ever timeout when switching to Legacy Mode. Tested on Chrome, Edge, IE, Firefox. Can someone running Safari go to CA's settings, enable developer mode, then hit Legacy Mode and confirm that it also works. (You'll see the pop up individually download the various repositories instead of just the spinning wheel) Other notable changes In the event of an appfeed failure, CA will check for and display an applicable "Public Service Announcement" that will state if I know the feed is definitively down. Appfeed download failure screen is more obvious that if nothing is wrong with your network settings to go to legacy mode. Various PHP warnings that could have appeared when displaying stats on a appfeed failure without switching to Legacy Mode have been suppressed. Download timeouts have been lowered from 60 seconds to 45. All new installs of CA now require you to actually accept the disclaimer before using the plugin.

Assuming the refreshes were in fairly quick succession. In that case, either you're downloading to the docker.img, or an app has out of control logging enabled (usually referred to within the app as "debug". Couple of entries in the docker FAQ about all this.

We're back in business

On a scheduled run, you'll see it logged in the syslog if it doesn't execute due to parity running.

If manually executing it, it really makes no sense to enforce the no Parity thing. So its only valid on scheduled runs

Yes