t3

I do (also) have stability problems (with any of the versions after 6.12.3)... the server is just getting unresponsive after some time (sometimes half an hour, sometimes a few hours; seems to happen sooner if the web interface is open on another machine). Does not longer respond to pings (no screen output due to GPU passthrough). Docker is disabled (always), have tried the Realtek driver plugin, but that did not help.... kvmhost-diagnostics-20240110-2319.zip

if you are running the image from their page (which would be my 1st guess), then there is an upgrade option right in the settings, called "Home Assistant Operating System" (that's it already). the other option is "Home Assistant Core" which just means the main HA application, if you don't run their specialized image, you may want to try and make a backup of your settings, and use theirs, from here: https://www.home-assistant.io/installation/linux hope it helps...

orphan post stub i just noticed that there was an update already ~ a month ago, that apparently did fail on my machine, thus my previous question regarding an update is now obsolete...

Not an advice, just some thoughts - since I'm currently (also) setting up a system dedicated to VMs only; I'm using an old Thumbdrive as only array drive, just to be able to fire up all the other Unraid stuff (KVM & Dockers of course). 2 NVMEs in a single BTRFS pool, since I like to have redundancy, and a BTRFS mirror seems to be more straight forward (and the Unraid array is not meant to provide trivial mirroring anyway). My concern ist the Fuse layer, which ist imo still in effect, as long as drives are somehow managed by Unraid (like with Pools). My guess: It might be best (in terms of performance) to just set KVM storage up as "unassigned device(s)". Maybe someone can shed light on how pooled drives are affected by Fuse when most (or any) IO is going to VM disk images...

Thanks for clarification!

Am I right, that a rebuild happens below file system level? So, e.g. if Unraid is rebuilding a BTRFS drive, it could/would/should be possible to scrub that drive afterwards, to make 100% sure the rebuild did work as intended? Short story why I'd want to do/know that: I knocked over my (running) Tower LianLi ITX with 10 Bays https://www.picclickimg.com/d/l400/pict/173424939301_/RARE-Lian-Li PC-Q26A-Mini-ITX-PC-Case-with-four-additional.jpg Pretty nice small enclosure, perfect for Unraid, only thing is, the drive bay locking mechanism is not super tight. So, even though all drives were spun down at that moment, and I'm almost certain that nothing bad happened to any of them, two of them did get disconnected for a few seconds, until I checked the seating of all of the drives, and ... of course ... Unraid red-X-ed them immediately. Apparently the only way at that point is to let Unraid do a rebuild, to get them working again (I have two parity disks). Btw, the Wiki info seems to be outdated (I didn't see any "trust my array" option or whatever else). So. from hard facts, since my accident may still have affected the integrity of multiple drives (including parity), I can't be 100% sure, that the (now running) rebuild is restoring perfectly valid data... but, in case my above thought is correct, a BTRFS scrub should be the way to ensure that after the rebuild is done.... right? Some final thoughts: I love Unraid, until the moment something goes wrong. Had that a few times, and for every of that instances, I felt at no point really secure, to have found the right answer to that particular problem; Almost certainly it feels like having applied the wrong measure (like now, since a drive rebuild seems to be not the best thing in that particular case, if not the worst)...

May I add, that Recycle Bin is most likely not the main culprit here (or any at all), just a symptom of an underlying problem with fuse. This same problem happens to me regularly for ~two years now, at completely "random" times, but usually when severe activity from various clients happen (Unraid is still a file server, after all). A couple months ago, it seems like I had identified Folder Caching as a possible reason, but even after disabling it, the problem still occurs, though less frequent...

didn't expect that. the plugin would still do that, on a file-per-file basis. but: if you have both drives, and there was no write-access after the rebuild, i guess there are some other (faster) ways to compare two drives; afaik they should be identical on a byte-by-byte basis, directly after a rebuild...

_after_ a rebuild, the plugin will allow you to validate the rebuilt files to have the same content, like when the hashes were created. in case they do, this implicitly also means, that the rebuilt went well so far. with one exception (as there is always one): the rather unlikely case, that the hash file itself was corrupted in such a way it had flipped one ascii character into another (since the hash is saved as ascii text). afaik there is no validation for the hash files themselves. ps: i guess you didn't literally mean to to compare a rebuilt drive with the original one...

Worked for me too! Using some "no-name" 4GB stick & W7x64 (drive name was the generic "removable device")

thanks a ton for that - just in time (for me) & works perfectly! a note for users with tight FW policies: this requires outgoing connections from the unraid box on tcp port 5223 (XMPPS), but that's already all it needs

yep, ok, thanks... scratch the first part - i should have read the integrated help, where it is stated that read errors are indeed backed by parity i'm now going to find my way through the replacement procedure(s)...

i did move some 300gb files off the array over night, und when i came back the next day, one of the disks (holding most of them) was offline; there were 7000+ errors printed in the main tab stats, and the syslog shows lots of sector read errors (and a few write errors). ok, disk is dead or dying - might be. but what does it mean for the files that were copied off that particular drive? apparently, the drive did not go offline on the first occurrence of a read error but after ~7000 of them, means some files were definitely read only using parity info, others apparently were not... so, were they corrected? by disk mechanisms? by additional parity reads? or are they now broken?!? would be good, i guess, if unraid hints users about if they need to be scared about the error count in the gui oh, and btw, i think it would be really, really good to have a simple gui-guided procedure to replace (or remove) failed disks in the most ideal way, reducing risk of data loss to a minimum. since this happens rather seldom, it simply means you are always (again) untrained, but it still touches one of the most important parts of unraid - data safety. so it's always again scaring to read through more or less outdated wiki articles and posts showing 10+ steps to follow, and to decide how to proceed on at this point - and i guess that happens to everybody in such a case...

great! btw, what do you think of the btrfs issue? is this something to expect in such a case? i must admit i didn't expect it...

OH YES i recently had exactly the same problem; i only discovered that one of the ssd cache mirror disks was offline for almost two months, when, after a power outage, where the the UPS power down didn't work btw, the system did some whatever repair on the mirror... which did then corrupt all vm disk images on the cache disk and the docker image as well. read on here; other user ~ same story: https://lime-technology.com/forum/index.php?topic=52601.msg505506#msg505506 speaking of btrfs' bad reputation: it seems that a btrfs mirror is no save place for docker/vm disk images! as far i can tell, the mirror only kept files intact that were written before or after one of the disks dropped out. any file that was changed in-place - like usually disk images - was corrupt after the mirror was reactivated even having 1+ backups for all and everything - having this situation going on unnoticed for such a long time is a bit on the edge btw, this means that unraid is already that stable and mature, that i don't feel any need to check the system every other day... so, yeah, a notification with a number of big red exclamation marks is very helpful!

a quick heads up for... ASRock C2550D4I and ASRock E3C224D4I-14S - also working w/o probs.

... as far as my files were affected, i can confirm it works now; tested with sync triggered from "both" ends (web and local) and all were showing up correctly on either side - thanks a lot!

thanks for hinting this; totally missed it, since there is no context menu/button/indication whatsoever that one can edit the names by simply double clicking them...

oh, and btw, it would be great if it was possible to set up a meaningful name for the dropbox instance prior linking...

i had some success "setting up" selective sync by copying a file from windows install over to the config folder of the docker; after installing and linking the docker, the dropbox config is created here: appdata/Dropbox/config/instance1 and contains a file named unlink.db since size and type and name suggested it might contain just everything that should not be synced, i just copied it from my windows box over to the docker config, and as far i can tell it works... of course only suitable if that is not going to change regularly. unfortunately there are problems with this docker with files that contain extended characters (i.e. german umlauts)... seems like the charset setting is missing or wrong?

well, no i can't say for sure about robocopy (not using it), bit what i see lacks the correct principle in first place. ok, tower2 is your master, and has all the proper *.hash files (the reference); you had also created them on tower1, which should be your mirror, but unfortunately they are useless, except you would write a script that can compare the contents of both towers directly from the hashes ('am not aware of such a tool). so, in order to use what you have... you would 1st delete all the hash files from tower1 (the mirror), and disable automatic hashing in the checksum tools setting (if you had set them up). now you can use robocopy to copy the hashes from tower2 to tower1, so the master file content and folder structure is 1:1 available on the slave, but just as sort of metadata. now you can either run corz over tower1, and it will find missing, different and extra files, as it is using the tower2 hash files as reference... but it will of course need to read all files and re-hash them during verification. another way would be to start a manual verification using the checksum tools in unraid. afaik (haven't done that) it will also report missing, different and extra*) files, since it is also using the hash files from the tower2 to verify tower1 contents, but of course this also needs to read everything and hash it. main advantage is that you don't need to have your client connected all the time, and most probably verification will run a lot faster when accessing the shares directly on the box. so, in short, there is no easy way to avoid on-the-fly hashing at least one tower, since there are no tools out there (of my knowledge), that will take (corz) hash files in folder structures to compare directories from two sources... *) note: i'm sure the plugin will report different and missing files during verification, i just don't know if it also reports files that are not hashed; maybe squid can tell...

afaik this won't work that way since corz has no comparison mode [for the hashes only]. if tower1 should be a 1:1 replica of tower2, you might copy the hashes files from tower2 to tower1 (i.e. using powershell to copy all *.hash files plus the full folder structure), and then run corz against tower1, to find out missing, different and extra files. there are probably other tools out there to synchronize/compare folders, but they won't make any use of the hash files corz/checksum tools had created, thus will need to re-hash everything on the run. antoher way would be to use syncthing (available as docker) to selectively synchronize folders; it allows to set a "master" (read-only) and uses sha256 to compare contents. even if it's definitely not meant to handle n terabytes and millions of files, i'm using it to create a mirror of my main server (sort of hot standby box)...

... thats the way any software goes btw, i wasn't completely precise - as far ipmitool can tell, the sensor in question simply doesn't support these particular "na" threshold values (means it also isn't possible to set them to something sane); i.e. true for most voltages on this board...

btw, thanks for pointing me to a way to correct threshold values using ipmitool. + found another small bug: my asrock avoton board has serveral values without lnc/unc values set by default (ipmitool returns "na") - this causes readings inside lc/uc ranges to be in orange/warning state instead green/ok...

i have just built 2 new boxes (both lian li q26) with asrock server boards: http://www.asrockrack.com/general/productdetail.asp?Model=E3C224D4I-14S#Specifications http://www.asrockrack.com/general/productdetail.asp?Model=C2550D4I#Specifications 1st one together with a e3-1231 v3 cpu and 32gb ram; 'am pretty happy with both builds. the e3 option is good for running multiple vm's and has plenty headroom for additional dockers and tasks like transcoding. as far i can tell the avoton board is also sufficient for at least 1 stream hd transcoding while running an additional vm (firewall in my case), but there is also an 8 core option of the latter (which should be able to handle a few streams in parallel). imo one needs to spend a bit more for capable mini-itx boards in comparison to i.e. micro atx, but since you have a nice case already it might be still cheaper to go this route. the computing power you can stuff into this form factor nowadays is in any way amazing...