Squid

No idea I deprecated it IIRC 2 years ago. tbh I suggest either running corz on another computer against your shares or switch to dynamix file integrity Sent via telekinesis

Now you should check for OS updates and get up to RC7, which doesn't have the problem.

It's because of the word "Share" An ad-blocker seems to think that the whole page is nothing but a link to share something via FaceBook. As an aside, the settings page for Fix Common Problems includes a test that *should* pop up a warning if an ad-blocker is interfering with the UI as a whole (and at least one user had an ad-blocker screwing with the Apps Tab because it had an element called "templates_content" and "MainArea" -> don't those just scream "this is an ad to you?") All in all, everytime an ad-blocker blocks an ad, any given website will change the element's name so that it gets through, and the ad-blocker then has to issue an update to compensate which results in more and more false positives, not just with unRaid, but with any given random website available.

Clicking Help should tell you, but Public - All users have RW access Secure - All users have R access, selected users have W access Private - only selected users have either R, W, or RW access And then you add in "hidden" which means that the user has to know the share name in order to access it as it won't show up in any list

If updating through auto update, update auto update (say that 10 times fast )

Incidentally, still no update showing on the container, the last update on dockerHub shows something like 4 months ago, and the dockerFile listed there doesn't have the quoting. Another thing also if it's possible. Currently the script is storing the intermediate file within the docker.img. Not a problem when I'm doing source files of 1-4Gig, but I will eventually start on doing source files of 50Gig+, and then it will become an issue.

Various coding improvements and minor changes across the board Renamed Trending Apps to be Top Performing Apps, and added in Trending Apps (which is the largest delta of trends) Support appfeed caching of icons * * You'd be surprised at just how many of the templates reference as their icons HTTP instead of HTTPS. CA has handled that for quite a while now, by automatically requesting HTTPS for icons instead of HTTP (it does this so as to not "break the lock" on the browsers by displaying mixed content). But, even with CA doing that, there were still a number of icons which were only available via HTTP and not HTTPS, and a few which in some webmaster's ultimate "I don't know what I'm doing, but they hired me anyways" moment that automatically redirect from HTTPS to HTTP which no matter what I did would break the lock again. Since this really annoyed me, all icons are now cached by the appfeed server and are always HTTPS, so you will always see the icons no matter what, and the lock will never break. The one gotcha though is that should the primary server ever go down, then CA's backup server will feed the original icon URLs which may or may not break the lock depending upon what you're dong.

To each their own. I'll never convince you, and you'll never convince me. But, I am convinced that I'm right

Gamble with what?

ok. How about my philosophy: I would always rather lose some than all in the case of exceeding the redundancy of my parity drives. If I have 3 drives die simultaneously, I figure that Murphy would say that one of those would be the one that has all of my wife's pictures on it, so I always keep data scattered over all drives. I could never understand why anyone would want say all episodes of a TV show stored on a single drive instead of being scattered throughout various drives. Or alternatively, with 2 simultaneous streams happening, with the files balanced out, the odds are reasonably decent that the streams will come from different drives instead of the same drive, reducing thrashing. Hence why I use Most Free as the allocation method, and whenever I increase the size of a particular drive I manually move the files around. To each their own

You need to add up the max spin up current ratings in Amps of the drives (available on the manufacturer's page) on the 12V lines, take a reasonable good guess at the amps of the mb / addon cards on the 12V and compare it to the amp ratings on the 12V line from the powersupply. The wattage rating of any given powersupply is a meaningless value, because it is the sum of all the wattage of the various lines. (IE: As an extreme example, nothing says that a manufacturer can't make a 1000Watt supply that is unable to handle the current required on the 12V line for 3 drives - although this won't happen in practice)

Did you add back to the template any/all of the path mappings which you had originally added to Plex?

It all depends on where you want the data stored. Initially, it looks like mover won't do anything, because your share's settings have mover set to do nothing

You appdata share is set to use cache:NO, which means that new files get written to the array (currently it exists on cache, disks 1&4). (And also mover will never touch it) Probably want to set it to use cache:Prefer Domains share is the same as above, but files currently only exist on the cache drive ISO's share is the same, but files exist on cache, disks 1&3 System share: ditto with cache, disk1

re: H265ize Looks like spaces in the input / output paths aren't being parsed correctly. Not sure if this is your docker build, or the actual script though. Setting /input to be /mnt/user/Television/Old Seasons/.... results in an error of [h265ize]: Input /mnt/user/Television/Old does not exist. Whereas if you escape the spaces in the path (which isn't necessary under normal circumstances since unRaid tosses quotes around it) will work eg: /mnt/user/Television/Old\ Seasons/...

Misunderstood you then. I thought you were suggesting that CA utilizing published repos on GitHub was not the way to do things.

What do you suggest as an alternative?

I just tried a clean install no problems. Maybe post the diagnostics

You could have checked off parity is already valid, but you would have to do a parity check anyways Sent via telekinesis

Yes. If you can copy the contents from /config/plugins/dockerMan/templates-user to the new flash then go to apps, previous apps Sent via telekinesis

Update AutoUpdate if you're using it.

Ok, then that explains these errors Apr 17 11:10:20 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 17 11:10:20 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Apr 17 11:10:20 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Apr 17 11:10:20 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 10 32 1a 00 00 02 00 Apr 17 11:10:20 Tower kernel: print_req_error: critical medium error, dev sda, sector 1061402 Your flash is trashed and needs to be replaced

I would assign static DNS addresses in Settings - Network of 208.67.222.222 and 208.67.220.220

Is this by design, or by accident? In what order are the .page files processed? Is /.../plugins/dynamix/*.page processed first and then everything else or is it done alphabetically by the folder name?

FYI, that command won't "solve" anything, but rather delays it from happening again. The solution is this https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564326