Squid

CRC errors are usually indicative of poor cabling / loose connections. Not usually a problem with the drive. Quite possible that if you yanked the cable on the drive to remove it you disturbed other drive's cabling at the same time. Because you formatted the emulated disk, you lost the files on it. Formatting on unRaid is the same as formatting on any OS. It wipes the drive. Rebuilding from parity will result in an empty drive. Unformatted means that because you pulled the power in the middle of a write, you got it at the exact wrong time when the system was updating the file structures / metadata. You needed to run the file system checks on the drive to recover and then rebuild. BTW, a UPS is always recommended on any server

Not that this is necessarily what happened to you, but a problem with AV scanners as a whole is that on signature detection, there is the possibility of false positives. http://cipherdyne.org/blog/2010/08/how-to-avoid-clamav-matches-on-bundled-snort-rules.html

Diagnostics are always preferred over a simple syslog. But, you've currently got bigger fish to fry. Disk 3 seems to have recurring read errors, and that issue should take precedence over the docker container.

You can specify the ROM file right on the template in 6.5 when you edit the VM Sent via Tapatalk because I'm either at work or enjoying the summer

Updates should have made it obsolete...

The plugin handles the appdata / flash drive (which has the templates on it for docker containers), so you're good there. For VM's, it only handles the libvirt image, which basically only has the xml for the VM definition. You still have to transfer the vdisks manually

So long as there's only one drive missing and/or redballed you haven't lost a thing and can still access all of your data. More than 1 then posting the diagnostics would be your best place to start Sent via Tapatalk because I'm either at work or enjoying the summer

Power? Pooched Motherboard? Any beeping? (although many mfg's don't include the beeper anymore so you can to add one) Fans running? Any change if you pull out all add-on cards and disconnect power from the hard drives? List goes on and on. A flash drive would probably have to have caught on fire and shorted out everything to prevent the motherboard from even posting.

Not to try and dismiss your issue, but random crashes etc are rarely the identical problem from one user to another, and are usually indicative of a hardware or power issue somewhere along the line.

Side question though. How do you know the flash drive has actually failed. Only LT would know the actual statistics on transferred registrations, but I would think that they are exceedingly rare (my one flash drive is older than all of my drives by far and still is chugging along)

99% of one of your syslogs (I really only looked at ...4970 which appears to be a FCP tail) is nothing but one call trace after another of Jun 30 03:56:56 Bunker kernel: INFO: rcu_sched self-detected stall on CPU The diagnostics look like they were after you rebooted the system June 30th ~20:54 IIRC, rcu-self detected stalls *seemed* to have disappeared from reports around here somewhere around 6.0-rc something. Whether or not this is relevant to your problems, I'm really not sure (when they were happening in early 6.0, I seem to think that they were more of an annoyance than anything else. Perhaps @eschultz or @limetech might have a better insight into this.

Because it didn't install. Unless you're talking about after a reboot, then with this particular plugin, that is perfectly normal -> It by design does not reinstall it self at boot up. Install Community Applications (you really should be using that for all add-on installations anyways), and there is a linked post on rclone that details why and the work around. Besides, troubleshooting plugin installations is easier if CA does or does not install for you.

Probably because at the time of "go" execution, the plugin isn't loaded yet. user scripts should do the trick

No idea about what you're talking about, but you can run a script at array start via the user scripts plugin

I had @limetech @eschultz add that module a few versions of unRaid ago, as I noticed that mcelog wouldn't work on the AMD processor, but I don't believe that it worked correctly. I have since moved on to Intel chips.

No good answer. It works for me 6.5.3. Are you hitting "Apply"?

What is your PS? What is your case? Hot swap bays? My first thought is that a ton of people have a million drives installed (as you do), and do not have any hot swap bays. Sata connectors suck. Beyond suck... Locking connectors (if the drive actually supports them, which many do not anymore) doesn't matter. Truth be told, the slightest corrosion and or breathing on the connector affects its connection. Since it pretty much appears that every time you replace one drive, you have to shortly replace another, this *implies* that in the absence of hotswap bays you're affecting the the cabling and/or power to the other drives (btw, power splitters as a general rule are also all terrible quality). What errors? Read errors actually never cause a drive to drop out. What happens in the case of a read error, is that unRaid (rightfully) will attempt to re-write the offending sector with the calculated value from parity and the other drives. If that write fails, then the drive gets dropped. Actual drive failures are exceedingly rare (although you do have a ton of WD's which I consider garbage compared to Seagate ) by and large, the majority of "failures" are cabling or power issues, and unless you're living on top of an old Indian gravesite, I'd say most if not all of your returns have been of good drives. This is indeed a sign of a problem (or potential problem) drive. What were all the other drives showing on the SMART reports for them?

Its an error on the template. Either wait for @clowrym to fix it, or edit that section and change it from a path to be a variable. -e PLEX_LOCAL_PORT=<plex_local_port> \

Are you assigning any dedicated IP addresses to a docker container? There have been reports of when that happens a trace winds up being issued, in which case it can safely be ignored.

Not without diagnostics (terminal, type diagnostics) when this happens

Never even looked at the dashboard. I go by whatever the docker page says.

Radarr for movies or Sonarr for TV. But, you really haven't supplied enough info for anyone to make an informed suggestion as to how to accomplish whatever you're trying to do.

But, this all makes sense when you consider @pwm's comments about what isolcpus does is stop the task scheduler from using those cores, so it would only wind up using the first core since scheduler is forbidden from touching any of the other cores. You should however be able to assign an individual docker container to which core you want (and other containers to other cores), but there's probably zero way to get the system to work the way you want as its by design on the Kernel

Oh. At least you stopped me before I posted a furthermore reply Sent via Tapatalk because I'm either at work or enjoying the summer

I can't tell what container is written by an maintainer vs one that's not (unless its dirt obvious) The one thing is that if an template author is beyond lazy and tosses up a template that CA converted, and leaves in the "...Converted By CA..." message in the description, it's automatically moderated by CA implying to users to not use it. It hasn't. If anything, its higher now that someone (pat on head ) actually checks stuff out. But I can't discriminate either. If a simple template adds value to the app eco-system, its in. If it doesn't, its removed. If the original question had been from anyone other than @itimpi, I would have ignored it completely. My opinion there is that if you can't figure out Who the author of CA is and who handles it or, Find the FAQ about what is required for inclusion in CA Then I probably don't want you in there. Most of the requests that I get for additions to CA don't fulfill the basic requirements set out in the FAQ. The repo does get added as a tentative, while the other requirements are in the process of being met. If after ~1 week the requirements aren't met, the repo gets pulled. Add in all of the automated checks that CA itself performs on every template present, and either the fixes it makes, or the automatic blacklisting under certain circumstances (lol -> lsio has one template automatically being dropped). And there are other tests I do on the applists via scripts here every once in a while that aren't convenient for CA to do itself every time a user loads it. You've got to remember also that I read (or at least skim) pretty much all the posts here. As far as problems with apps are concerned, the ones that catch my eye are ones that don't work out of the box. On any post like that, its an automatic -> I install it. If it works for me, so be it. If it doesn't work action gets taken. But, of course I'm not stupid either. Every single user of CA has had to agree to the "Cover My Ass" warning when installing before they are able to use it. And yes I know that I'm sounding a bit defensive here. You are right there, and point taken, but I think that's more of an education thing than something which I can easily moderate, especially since the internet effectively give anonymity to everyone. Nothing says that the owner of the github repo for templates can't have a separate account for the docker builds, and in the case of non-automated builds, you can't even find the github repo for the build itself. Which is why in CA and on the docker/dashboard drop downs there is are separate links to Support Threads / Project Threads. Like I said I have no problems with support threads themselves being hosted on another forum. I agree. Especially since the app is both timely, popular in the hardware sense, missing from CA, and certainly worthy of inclusion. The ultimate test here (and with any app) is how good it is, not how good the maintainer of the template or container is.