RobJ

Not an expert here, but I think most would say go into the Windows Credential Manager and delete all credentials. Then try again.

Great addition! I'd like to request though that you do add the super.dat file to the backup, but rename it. Often, it's the one and only file that's needed from the backup. If it's renamed, it has to be a conscious thought-out decision to use it, won't be automatically used. Another idea, since the single biggest risk of the wrong super.dat is a parity drive change, why not rename the super.dat to include the model and serial of the parity drive (e.g. super.paritymodel_serial.parity2model_serial.dat). At a glance, the user will probably know if it's OK to use. While a slot change for a data drive or a drive addition is an important change, neither should cause data loss, and should be apparent on first array start, if it even can start. A parity drive mistake however can be disastrous, and may not be immediately apparent. I also like the idea above to create a text file with the current drive configuration, name it something like superdat.txt? I assume that at some point, you'll add the ability to configure the flash backup destination path?

My point of view - we've been trying to isolate the NAS parts from everything that might negatively impact stability, and that includes anything plugin-related. Unfortunately, as we all are aware, that's been a losing battle lately, with numerous good ideas resulting in more and more plugins, each justifiable as a plugin too. But media related stuff, I don't think there's any way to justify it. Again it's just my opinion, but I really vote against a MediaPack. Those needs would be MUCH better served in Docker containers, isolated from the core NAS. I'm a little less concerned about a DevPack, because those tools should almost always be safe to run, and they're usually used briefly, a temporary usage to build something, plus they probably build better based in the bare metal configuration. BUT ... the first thing most of us would want to do is test what we've built! And that put's it squarely in the ought-to-be-isolated category! Probably better to build a Docker container or VM that as closely as possible emulates an unRAID environment. Best would be a packaged unRAID dev VM (doesn't need fancy graphics). PhAzE's success worries me some, because it encourages so many users to run unstable and constantly updated media tools in the core. It's a tribute to how well he's managed it, but it is not a good choice from a NAS point of view. Users doing that should realize their NAS is not being treated as a 'mission critical' component. How can anyone not be concerned when you see the number of users clamoring constantly for the latest Plex or other complex media tool, and adding it to their core unRAID system, knowing that it has barely been tested. I don't see how any good IT person could approve. It lets inexperienced users take the easy way out, and potentially shoot themselves in the foot then blame unRAID (hasn't happened yet, but it's probably coming).

It's not usually necessary to cache the User Shares, since they are already in memory. And I strongly recommend setting the Included folders, include only those shares and folders you actually want cached. I have additional comments about the CacheDirs plugin in the Upgrading to v6, Dynamix Plugins section.

Under \\<Server>\flash\preclear_reports\ Did you perhaps mean \\<Server>\boot\preclear_reports\ ? I don't think so. That was a UNC network path as it would be specified from Windows. Don't know about others. The boot drive is the flash share. Of course you know that so maybe I'm misunderstanding your point. No, you're right, my mistake.

Under \\<Server>\flash\preclear_reports\ Did you perhaps mean \\<Server>\boot\preclear_reports\ ?

We're all learning! We can now add this to our toolbox.

Thank you for providing this! I'd be very interested in hearing your conclusions from the above, as well as from anyone else with mcelog experience. I can't claim any experience, but did do some research - to me it looks like a defective CPU, bad level-2 caching. I did note though that a few persons with the same errors were able to get the CPU to work once they disabled CPU power state control, such as turning off SpeedStep or the like. I'd like to hear how that jibes with your experience. Some were able to get their CPU to function by trial and error disabling of various CPU features, not really fixing the CPU, but avoiding the defective parts. Some were able to function by using different versions of different OS's, often older ones, possibly because the older OS didn't use a particular CPU feature.

Any text editor, or the one built into the webGui - just click on the flash drive on the Main screen, and drop down to the syslinux editor.

Do we need mce-inject and mce-test too? http://mcelog.org/testing.html I don't have any experience with it to know how necessary that is. Plus as dmacias said, we'd need it enabled in the kernel to even try. In general, I agree it's always wise to test your tools before you need them. Perhaps someone creating a custom build of unRAID and kernel can play with it, let us know how well it works, and how best to utilize it. I think we're more likely going to have to go by what happens with those users who report MCE's, with mcelog loaded.

It installed without any issues, but that's all I can say, I can't get it to report anything. Different commands reported errors consistent with bad syntax, and no issues appear in the syslog, and there's no mcelog created. So it may be working, but I can't confirm. And I don't think I have ever had an MCE. A little surprised it didn't report errors with my DMI info, as that is really messed up in my old BIOS.

Thanks for adding mcelog for 6.2! I'm still running 6.1.9, and of course it isn't showing up. It would be nice for 6.1 users to have it too, if that's possible, not too hard? If Tom adds it, he would only add it to 6.2 not 6.1, so 6.1 users would still appreciate it, even more.

Doing some research online, and I guess the best statement I can come up with is that when devices show these errors, they are currently incompatible with either VT-d or IOMMU. Why 'currently'? They may need an update to their firmware or their driver to better support passthrough or IOMMU. Or, the system needs an update to the BIOS for better support of IOMMU, or the kernel needs an update to IOMMU or the passthrough support. Apparently, buggy motherboard BIOS's and buggy drivers and firmware are common. So I guess the best advice is to keep looking for updates to firmware, BIOS, and Linux kernel (the kernel core itself as well as the virtualization support, especially IOMMU, and the included drivers). Some workarounds that are generally suggested, with possibly undesirable side-effects (choose only one!) - - iommu=pt - iommu=pt r8169.use_dac=1 - intel_iommu=pt - intel_iommu=igfx_off - iommu=off - intel_iommu=off - replace problem hardware - disable virtualization support in BIOS Disclaimer: I'm certainly not an expert in this area.

Perhaps you meant to post this in the System Temp thread? Edit: hmm... I thought there was a System Temp support thread. It appears to be the catchall thread instead, Dynamix - V6 Plugins.

What's my prize? (If the deadline is past, I actually saw it a week or 2 ago!)

A very minor point - you added a message to the popup to indicate all drives would spin up, a good idea at the time. Then you added the option to only test spun up drives, another good idea, which I have enabled. All of my drives are generally always spun down, and stay that way, but we still see the message about all drives being spun up. Perhaps it could be removed or altered, conditionally?

In that syslog, there were no issues, but they hadn't been used yet, other than mounted. A parity check would run them hard, so you may have a problem with that card overheating. Something may be wrong with the card though, because it shouldn't overheat with only 2 drives attached.

This is what the kernel is currently seeing: 02:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios Logic SAS2308 PCI-Express Fusion-MPT SAS-2 [1000:0087] (rev 05) Subsystem: ASUSTeK Computer Inc. Device [1043:8583] Kernel driver in use: mpt2sas Kernel modules: mpt2sas In this 6.1.9 syslog, it appears to be working fine! You have 2 drives attached on it, Disk 4 and the parity drive. Are you still seeing issues?

Please see Need help? Read me first!, and attach the diagnostics zip. The small syslog pieces are only slightly helpful. I'd have to say, just from the syslog excerpts, that your SAS card is not compatible, don't know why. Are you sure that there were unRAID user reports that your SAS card worked with unRAID? Cables won't help, it's the card that's non-operational.

Wow! It does sound so appealing!

I'd say the drive is fine. It showed 5 questionable sectors at the start, but the first zeroing resulted in none, not remapped either. Very likely, they were the result of a power spike that scrambled them, not actual bad sectors. Then you did 2 more Preclears without any changes or errors found.

Tested with and without driver - works well. Thanks! Now to see if anyone else besides me has the problem!

I didn't know that! I thought moderators and admins were the only ones who can make changes. I make the occasional edit on Wikipedia so if the procedure is similar this is something I'll definitely investigate. This is very belated, off-topic in its lateness ... I am ALWAYS looking for more users that might be interested in contributing to the unRAID wiki, thank you for your interest! There are only a few pages off-limits to users, pages like the official unRAID Manual 6, etc. All of the rest are fair game, waiting eagerly for attention. And you don't have to be a good writer, just want to help. People are needed for original content, corrections, formatting and style, proofreading, keeping pages updated when things change, adding new ideas, adding hardware listings, etc etc. I'd love to see users take responsibility for individual pages or sections of pages, making sure that section or page stays up to date. I've created a page Start Contributing just to help you get the syntax. It's simple, only takes a few minutes to get the basics. I recommend just a quick skim of it at first, then refer to it later as needed. It's MediaWiki syntax, so if you have contributed on any other MediaWiki site, such as Wikipedia(!), you are already good to go! I hope to see lots of new editors! And it's constantly monitored, so mistakes and mischief will be quickly corrected. Who and when can you edit? Any user with a few posts and is logged in on the forums. It's the same login for both.

I'm not completely sure what you meant by '4 pin power'. You may already know this stuff, but I just found a great tutorial on the differences between 2 pin, 3 pin, and 4 pin fans -> here

Looks perfect!