Alyred

Sorry for a dumb question, but I'm trying to find where the instructions are to enable the module and not seeing them. I'm getting the daemon connection error but can't see where in the plugin description on CA or the description of the plugin on the plugins page in UnRAID it says where I need to enable a module or how to do so. Is it the "test" button within the plugin UI page?

Hi @ZappyZap thanks for updating the container! Do you post changelogs for it anywhere? I couldn't find one but I might just not be looking in the same place. Seems to be working fine but was just curious on the latest changes that have had a few updates this week. Thanks again!

All good now with 10.20.1. Thanks!

So, I saw there was an update to FolderView and ran it on one of my servers without issue, but then when I tried on the second server it alternatingly put it as "Unavailable" from the plugins page when checking update status to "up to date" when refreshing the page. So I figured something was corrupt and uninstalled, but when I went to re-install I got an XML missing error and now the CA page just says "pending" with no interaction when I click on it. plugin: installing: folder.view.plg Executing hook script: pre_plugin_checks plugin: downloading: folder.view.plg ... done Executing hook script: pre_plugin_checks plugin: XML file doesn't exist or xml parse error Executing hook script: post_plugin_checks Everything else seems to work properly on the server, but it doesn't appear I can even trigger it to check/try again now in CA.

Saw the update, thanks. Any reason the "preview vertical bars" dividing containers don't follow it as well? No worries if so, I understand it's a frivolous request . Everything works well and looks great! Awesome work.

Dang, fantastic work you've been doing, loving the updates and continued support, @scolcipitato! As a minor tweak, can you have the vertical dividers (if enabled) and horizontal dividers (at the bottom of folders when you expand them in the docker tab) either follow the preview border color you added, or their own color selectors?

Yep, CTRL-F5 did it for me too. Haven't had to use that ol' trick in a while! Fantastic work! Thank you, definitely agree the new folder.view is better than the old by far!

Minor feature request: Any possibility of putting in a hex color (and maybe disable) option for the border of the folder preview/divider in the docker tab? It's nice having the border but the white is a bit bright.

Really like the newer spacing between the status, WebUI, and Log button. Looks great! Thanks for the continued updates!

You have to add in the data:image/svg+xml;base64, string at the beginning, but this site accepts animated SVG images (I used the ones that people had created for the old plugin): https://base64.guru/converter/encode/image/svg Had the issue a couple of others reported about my dockers being out of order when I created my first folder, but moving one around and then refreshing did the trick. Looks beautiful. Thank you @scolcipitato for the work and bringing this plugin back anew.

Quick question: Any reason that FCP still tells me that I have multiple NICs on the same IP network? One of the cards is passed through to a VM. While I've got that warning set to "ignored", it's a valid configuration.

Unfortunately, I don't have any help I can provide but I just got this at 4 AM as well, a few hours after installing a new version of Fix Common Problems. Server is running smooth as well, problems that I can find but unsure how to pull this log (I'm on an AMD and trying mcelog from the command line just throws an error that my processor isn't supported. I don't think the advice about getting the NerdPack installed really is applicable anymore; I'm going to acknowledge the error and see if it comes back up again. I noticed FCP just got updated again...

Thanks for the clarification. I keep a tab open fairly regularly, especially while I'm getting a new server going and monitoring a few other factors before I deploy it in prod. So yeah, it looks like it was just powering on as soon as it was spinning down. Bummer that there's no way to query or skip specific drives in the ZFS system, but at least we know. Can you extend the maximum time option between automatic refreshes, and whenever the plugin is used/a button clicked to create/edit/destroy something? Seems like it wouldn't need to be updated too often in some situations for anyone that doesn't make too many changes. Otherwise, I could just use the dashboard more often than the "main" page...

Regarding array disks not spinning down: I've set the re-scan time to 5 minutes, but is there any way we can have ZFS master exclude disks so that we can prevent them from spinning up? Or as a feature request, only scan a drive if it shows as spun up, or only spin it up if it is making a change in ZFS snapshots/datasets? Having my drives that aren't being used spinning up frequently eliminates one of the main reasons for using UnRAID (power saving/heat reduction/noise reduction on low-use drives).

It seems it was ZFS master. I'll make a post in that plugin's thread to maybe only scan drives that are active, since ZFS can now be in the main array. The maximum timeout is 5m which I set it to, but no need to keep spinning up disks that wouldn't have any dataset changes if they haven't been spun up since the last check.

Hm, good possibility, though why would it only be starting one of the empty drive but not the other? I'll dig in on that lead amd see if I cam find anything.

Hi everyone, trying to still work out some kinks in my newly installed server. It's not been busy doing much of anything, has one VM and one container running on it, and sits mostly idle. There's not even any files on Disk 2 or disk 3, and the ones on Disk 1 are just isos. Disk 2 used to contain my system share, but I've moved that off and it now shows nothing there. I even re-created the share directories on each of the disks, then used touch to create a file there, then had mover move them back to the SATA cache pool, which then as expected deleted the share directories off the disks since they were empty. I've tried disabling my docker and VM services completely, and still the disks spin up. Interested in any thoughts for what to try next, or if anyone can tell what is causing those three disks (but strangely, never Disk 3) to spin up from my diagnostics. Thanks in advance. moissanite-diagnostics-20230718-1223.zip

It's static/configurable MAC addresses you can't have, which are needed in some configurations (certain routers, reserved IPs mapped to MACs, etc). Mapping to IPs works fine and IPVLAN works for most folks. I had to change one container that I was using a redefined MAC address to help spot new devices on my network when I changed it. No other issues (on that server, anyway).

Where would I look specifically for the VM system logs and errors? Not for the individual VMs but for the virtual system? The problems/crashes only started happening when I created and began running a VM, and then I noticed something when looking around - somehow, my System share was still stuck on my array. I thought I had moved it off long ago but the entire thing was still there. So I just stopped the VM and Docker services, forced mover to finish, then removed the secondary storage so it was exclusive to my SATA cache pool. Restarted my VM and container and let's see how it goes. I'm wondering if something trying to access the system share while the array disk was spun down, or something with timeouts relating to that, might have caused the system reboot/crash? Memtest ran fine with zero errors over 14 hours. I also double-checked my BIOS settings. At one time I had tried to use the curve optimizer to slightly reduce the voltage to the CPU (-10) but had turned off PBO altogether, which made the curve optimizer settings go away. I had assumed those would have been reset but maybe not; I re-enabled it long enough to set that back to 0 and then re-disabled PBO. Currently Global C-States is still enabled, and left Power Supply Idle Control set to Typical. Going to let it run for a bit and see if moving the system share to the SATA pools help, without mover bothering it or it being on a possibly spun-down array drive, etc.

The server is running on a UPS that doesn't seem to be causing issues otherwise; there's another computer plugged into it but sleeping for the time being as I'm using the monitor and keyboard while I'm building the server. It hasn't restarted or been interrupted. I believe it's set to stay off if the power's been interrupted. That's how I usually set it because I don't want them powering on when the UPS comes online after a power outage or anything like that. I don't know of anything else that might be causing a restart, after a day or two of running without issue I just come back to find the array offline and the uptime has recently restarted. Here's the syslog. It covers both the recent restarts. I'm currently running a memtest on it because why not. syslog.txt

New server rebooted again just a few minutes ago. RAM was set to 2666 Mhz/not overclocked, BIOS setting for Power Supply Idle Control set to Typical. What should I try next? DIagnostics attached. I still have my syslog mirrored to flash and can upload that too if necessary. moissanite-diagnostics-20230716-0043.zip

In your appdata/binhex-delugevpn/wireguard folder, there's a wg0.conf file. If you used one of Mullvad's wg conf files, the initial comments in the file should still be in the wg0.conf file that has the connection name. If you manually built it, there's probably not a way to find out which is which and best to just remove them all from Mullvad's account page, then regenerate new ones and re-apply one of the wg.conf files they provide with the connection name as a comment in the conf file.

Thanks. Have it fixed to 2666 mhz now and XMP turned off, upped the voltage a tad to 1.250v for a bit more stability since I'm not having heat issues. Edit: Decided to just run it at "auto", which is 1.200v. This is a good point, though it was running fine through all of my weeks of trying to get the Preclears to work properly (I believe these were related to other issues, certainly no crashes) and didn't start crashing until I began configuring a VM hosted in the server.

Right, thought I turned off XMP when I got the Power Supply Idle Control, but apparently didn't save that config. Question for future visitors: Are you seeing that as part of the syslog error I posted (with the Hardware error), or something else you saw in the diagnostics? I'll get XMP disabled (though seems a waste, especially since it was stable for months in TrueNAS) and let it run to see if I get further lockups.

So it just restarted again this morning. I do have the syslog from the syslog server being mirrored to the flash drive. Not sure if that's safe to upload in its raw form like that? Happy to do so if needed. This is with the Power Supply Idle Control set to Typical still in the BIOS. Glancing through I see the following "hardware errors" logged during the bootup I believe: Jul 14 08:17:26 Moissanite kernel: microcode: CPU0: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU1: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU2: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU3: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU4: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU5: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU6: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU7: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU8: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU9: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU10: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU11: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU12: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU13: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU14: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU15: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU16: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU17: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU18: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU19: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU20: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU21: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU22: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU23: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU24: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU25: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU26: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU27: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU28: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU29: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU30: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: CPU31: patch_level=0x0a20120a Jul 14 08:17:26 Moissanite kernel: microcode: Microcode Update Driver: v2.2. Jul 14 08:17:26 Moissanite kernel: IPI shorthand broadcast: enabled Jul 14 08:17:26 Moissanite kernel: sched_clock: Marking stable (1536275102, 317374787)->(1886336138, -32686249) Jul 14 08:17:26 Moissanite kernel: mce: [Hardware Error]: Machine check events logged Jul 14 08:17:26 Moissanite kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 5: baa0000000030150 Jul 14 08:17:26 Moissanite kernel: mce: [Hardware Error]: TSC 0 MISC d012000200000000 SYND 4d000002 IPID 500b000000000 Jul 14 08:17:26 Moissanite kernel: mce: [Hardware Error]: PROCESSOR 2:a20f12 TIME 1689347821 SOCKET 0 APIC 0 microcode a20120a moissanite-diagnostics-20230714-0944.zip