Squid

Nope. It's a package that's included in 6.3.3+

Stop the array. Main, Cache Device, Change the format type to what you want. If its already what you want and just want to reformat it, then: Change it to anything else. Start the array. Format the drive Stop the array Change the format type to what you want Start the array Format the drive

<div class="adsitem"></div> . . . if ($('.adsitem').length==0 || $('.adsitem').css('display')=='none') { alert("Ad blocker detected. Ad blockers can interfere with the GUI of unRaid, and it is recommended to whitelist your server in the ad-blocker settings"); } If that div is messed with by an adblocker (removing the div or setting it to not display), then the alert appears.

Because the flash drive was offline, no matter what unRaid will want to do a parity check (because it couldn't save the fact that it was a clean shutdown) Your decision to make is was the shutdown actually clean or not? If you think it was clean, then cancel it. If not, then either keep the parity check running or cancel. Up to you...

each line

Yesterday at 4:22 p your flash drive dropped offline which is the cause of all of this. A reboot is your only real recourse, but if the flash isn't already in a USB2 port, you might consider popping it in one

Always on this its best to email [email protected]

Plugin page problem. Best guess is that your server has a bitch of a time communicating with GitHub.com What happens if you go to settings - Notification settings, and disable the OS Update check and plugin update check, and then go to the plugins page? Docker Apps: Only suggestion to to delete the docker image (Settings - docker - advanced view, disable service, delete the image, re-enable service), and then re-add your apps via Apps tab, previous apps (check off all your apps, then Install Multi)

Passed thru videocard? If so, would make sense

File(s) in use won't get moved. If you go Main, Cache Devices, then you can browse the cache drive by clicking the folder at the far right to see what's still there

You can also prioritize any docker container over another CPU wise See here:

I admire your persistence... Personally, I would've given him crap. Oh wait, I did

Hmm.. Post #'s only appear in tapatalk, and I'm not in the mood to start at page 1 and count

This is what I've decided to do: I've removed the following tests: Docker Network type not matching the template (host vs bridge). Docker Container Ports changed or missing Docker webUI link changed unRaid 6.3+ makes it far harder to mess with the container ports as an example unless you know what you're doing in the first place, and Network Type mismatches are not always indicative of an actual error in the application running. The webUI link tends to get changed if you run the apps on a reverse proxy. Basically, these tests while there still may be a place for them in limited circumstances are starting to become more troublesome than they are worth, and the legitimate changes to them are only causing false positives

If you're looking for your eap controller app, there's fatal errors in the template https://tools.linuxserver.io/xml/2431b2f77008990320afd61e4fd3de16308f8c0e.xml

First things first, you've got at least two drives that have very poor connections One looks like your unassigned Samsung, and the other I cannot discern easily. Both are basically doing nothing but connect / disconnect continually. Reseat all cabling to all drives. After that, reboot and try and replicate the problems again and then repost your diagnostics. The syslogs should be much easier to read then.

Ignore it. Problem is that FCP is seeing another template from a different repository that happens to be blacklisted but refers to gitlab/gitlab-ce which has those ports defined. I'll have to redo that test to account for it not looking at a blacklisted, duplicated template

The errors are ignored. They will still display on a rescan, but they will not send a notification when found.

There's still files on the cache drive. You can browse the cache drive via the UI to see what's still on there. Or you don't have a parity drive

1-2 hours generally

When the share is empty, go to the shares tab and you click the share and they'll be at the bottom a "delete" checkbox Doing via Krusader should have worked. delete the shareName from /UNRAID/user/shareName Alternatively, from the command line, rm -rf /mnt/user/shareName

Here's what happened. The first server saw that there was an update to the appfeed, and proceded to download it, but the appfeed server gave it a cached version. Your test server also saw the update to the appfeed, but the appfeed server didn't give it a cached version. Provisions are now in place that if CA recognizes that it's been given a cached version of the appfeed when an update is available, it will on the next load (and subsequent loads) try again to get the appfeed (and keep trying with every load of the tab to get it until its received the updated version). (I just caught the appfeed server telling me an update was available, but it decided to cache the old appfeed for ~45 minutes). Previous behaviour would be that CA wouldn't try again to grab the feed because as far as it was concerned, it did get the latest version.

Point of this container is to configure Sonarr / Radarr to send the signal to it to rescan / update the library upon a completion of a download.

unRaid 6.4.1? Uninstall the Advanced Buttons plugin if you've got it.

Makes sense. Had to ask.