NLS

Just a note. I made Geyser work with this server after all. It always showed as working (when server started it reported geyser loading and listening to 0.0.0.0:25575 - that was ok from the beginning), but in reality it was unreachable (from own LAN). Don't know what made it work but here are some things I tried: - Made login mode floodgate (also have floodgate). It shouldn't be this, because my issue was that server was not even responding from bedrock client. I did have to whitelist the player when game worked (it didn't show with same UUID). - Made an extra port setting in the container where I also "opened" UDP ports for Geyser (as I noticed it kept mentioning about UDP port). It could be it. ...some other things I don't remember (not a very useful port eh? )...

It's pretty clear that it was a very useful plugin. Hope it somehow survives.

#2. They were installed using CA. I am pretty positive I didn't use a manual compose or anything. Remember CA DOES update them (or UNRAID does it?), even though it doesn't show them as installed. Is there a way to "force" CA to "see" them? (they are in the same place that CA puts them anyway) Is there a file to check or edit or something?

@Squid hello, two things to report I just noticed 1) I tried to update two containers right from CA interface (instead of UNRAID dashboard I always use). CA reported that they needed update so I tried through CA just to check it out. Well... both failed. It opened a white window where it listed the process/progress, but it failed to build the first container, then failed the second. It continued being "blue" (even after page refresh) in dashboard, so I updated from "docker" tab. This time it didn't load any new packages (signifying that probably through CA it *did* get them), but the container command was successful this time. It might just been some hiccup, I will try it again with next update I see. 2) I just found out that two of the containers I use (maybe more actually, but certainly just few), although they are installed AND used AND even updated (one was even updated today), they don't report as "installed" in CA. The two I found were from linuxserver's repo, but this could just be by chance, as other containers from that repo show as installed properly. One that doesn't show as installed is qbittorrent, other is syncthing. Not easy to re-install any of the two (scared to lose their config). (please tag me as I cannot follow this huge thread)

Yes please. I configured it (I think) - but it never worked.

I have no graphics in the stats. Even after I applied this:

Hope this is fixed soon.

I edited my OP just to add an "S" to "year" (that I use UNRAID). I suspect 1 year vs 15+ (with a break in between) must be different. (including how much noob, people consider you when replying )

There are very nice GUI based duplicate finders in the apps.

To be honest, I have already tried to ignore possible risks in the yearS I use UNRAID and use my server more or less normally. BUT I would like to have some expert (or official) feedback on how UNRAID handles a file write (or many files write), while data are rebuilding on a disk. And before people saying that writing usually involves the cache, because it is not always the case... (a) people without cache, (b) shares that are "no cache", (c) file deletes (that also affect the contents of the disk). More specifically, how does it handle writing: - to a functional HD in disk blocks that the data rebuild has already passed over. - to a functional HD in disk blocks that the data rebuild hasn't yet passed over. - to the emulated (and data reconstructing) HD in disk blocks that the data rebuild has already passed over. - to the emulated (and data reconstructing) HD in disk blocks that the data rebuild hasn't yet passed over. ...and the rare case that the filesystem tries to use blocks on functional or emulated HD... DURING the passing of the rebuild from those very disk blocks. I want to assume that UNRAID handles all those cases gracefully somehow. But is it the case or someone plays with fire when writing to an array while rebuilding?

Yes that is what I thought, but I open the XML and I cannot find that "device". That's the issue. I actually created a new Win11 VM (just to make a fresh XML) and the only difference between the two XML is this: (all other lines are same or have reasonable differences that I can explain) Old (with problem) <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </memballoon> New (haven't tested though) <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0a' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </memballoon> So is it the different bus of VirtIO? Is it the extra "subsystem" that the new VM reports (and added to XML)? EDIT: WAIT! It is the other way around! The problem VM has the extra lines! So it probably is that. I will try. EDIT #2: Seems that was it. I am not sure what I lost by removing vfio subsystem...

I will try the first. I think this mobo has an ITE chip. I installed it but doesn't detect anything. Maybe reboot the system first? The other (NCT6687), although I didn't have explicitly installed (as a plugin), it was already there probably because of my previous mobo. But I don't see it in my plugins, how can the system try to use? Even when booting UNRAID, I see in the boot scroll that "nct6687" fails to load at some point. Why it tries to use it, when I don't have it installed? I even pressed "unload drivers" in the plugin.

I changed motherboard (and added a NIC card) on my server and now one of my VMs doesn't start. Just one, with Windows. It reports: I tried to edit the configuration (from GUI) but I don't see any "0000:0a:00.1". Help?

I am confused. Someone should probably EDIT the first post of this thread to point to the latest news about this plugin, its fate, how to manually achieve the same effect, instead of browsing through so many pages. I for would love an updated version of nerdpack, as it made some things much easier.

Is it possible to add Gigabyte X570-UD support to System Temperature plugin? I recently changed server motherboard (erm... twice) and now I miss motherboard temperature and it doesn't detect the sensor device to load the driver. It actually tries to load the previous one (and I see an error during boot for exactly this reason) too.

I thought of that but I don't think this is comparable to full actual surface test.

Seems it was indeed the cable. Which SUCKS as for whoever followed my three latest threads, can see I got all kinds of cable errors. And OK parity disk is on normal SATA cable that goes on mobo. The others are 1-to-4 SAS/SATA cables that cannot be replaced very fast (need to be ordered from ebay etc.). Anyway... now parity builds the emulated disk, with 0 errors until now (3.2%). Knock on wood. (then will replace the parity with bigger new, rebuild, then replace the very old temp 3TB that builds right now, with new bigger and build YET again, then use the old 4TB parity to replace one more older 3TB data disk and yes... rebuild AGAIN) Note: I never a reply on how someone could possibly (surface?) check the parity disk.

I am going to wait for the parity build to finish (it is more than 70% now). I am not close to the server anyway. Or should I just stop it so it doesn't come online? Assuming it is the cable, the proper procedure (after replacing) is what? How can I enforce to rebuild disk 9 from the start? Delete whatever partition it created? Also is there any disk check appropriate for parity? (before starting rebuild)

...erm actually just noticed in the GUI... Current operation started on Wednesday, 28-09-2022, 07:34 (today) Elapsed time: 4 hours, 51 minutes Estimated finish: 2 hours, 32 minutes Finding 219564171 errors The number is a bit unrealistic. So, could again be a cable issue, and is that on parity? Yes it is on parity as I also see this: Parity WDC_WD40EFRX-68N32N0_WD-WCC7K6SYT2RN - 4 TB (sdb) * 493 984 963 5944 224 437 515 So, about half the reads (!?) fail? Any ideas? Also is there any disk test appropriate for the parity? (that I understand doesn't have a proper filesystem?)

So my syslog got full, while rebuilding a disk from parity (as seen in my previous threads). The rebuild is still around 50% and progressing without any report of issues in the GUI, although it did pop up about a single error (probably bad sector in parity?)... but from that point no further issues and if I didn't notice the log getting full I would think things are ok. So the lines that fille up syslog are as follows: Sep 28 10:17:59 <my server> kernel: md: disk0 read error, sector=2169270496 (with the sector keep changing in the every line) Last entry (because it filled up) was 70 minutes ago (10:17:59 or something, local) and I am about 4 hours in the rebuild already. So I looked to find the FIRST such entry in the log. What I found was very interesting. The first entry in the log, more than 1.5 million lines above the last, WAS THE SAME MINUTE (10:17:06). It actuallly "burst" 1.7 million lines in the same limit, so I double it correctly identifies the error. (Is it realistic to find 1.7 million sectors with problem within 50 seconds? Plus who know how many more after log was full?) Also I am not sure which is "disk0" as I don't have that anywhere. Is it the parity? What is happening? I post a truncated version of the log. syslog.txt

Yes didn't realize at the time that it was the same issue practically. Thanks.

See here what happened next: (different issue, thus different thread - plus will contact support)

This is a continuation of what happened here: ...but a different issue that I suspect will need the assistance of LimeTech themselves. So... a short version of what led to the CURRENT issue: 1- Two disks broke down (I broke them down... this is where the previous thread stops). 2- I managed to fix one of the two (hardware fix - actual data not touched), so I re-installed it and wanted system to start in non-redundant state and emulate the missing one. (I have done it before more than once on other cases, I know how it works perfectly well) 3- BUT when I first started the system with the fixed disk, somehow (probably cable issue) another disk (a third one), reported many disk errors. NOTE: This is the only time I actually started the array (the third disk didn't report issues before starting the array). 4- I brought system down, checked cables, restarted system. The third disk reported ok this time, BUT ANOTHER DISK (fourth one!), reported missing. 5- That was again a cable re-seat issue. I restarted the system after cable check... AND HERE IS THE ISSUE... All disks (except the one actually broken down and missing) reported ok this time BUT for some reason after that boot the array started automatically (didn't boot stopped to allow me to handle any issues like the missing disk). Somewhere between steps 3, 4, 5 above, the broken down missing disk (that was supposed to be emulated) SOMEHOW (I didn't do it by hand) showed as "unassigned"!!! Which means that the system actually thinks the array is originally with one LESS disk, not emulating the missing one! Again, I didn't do that by hand (remember I manually started the array ONLY on step 2, not on the next reboots), but somehow the system got confused between different missing disks. So IS THERE A WAY to somehow tell the system that the "unassigned" position needs to be emulated again??? The parity should be untouched so the emulation of the missing disk should work (and parity should actually be INVALID with the current supposed unassigned position and the system doesn't even know that yet). I immediately stopped the array so that parity remains untouched. I don't think any write took place in the less-than-a-minute time that it was automatically brought online. I have on record the full ID (I believe) and serial of the missing disk if I need to manually enter it somewhere. I should be able to somehow edit the configuration manually??? Heeeelp? EDIT: I have ordered replacement disk(s) already. If I make a new configuration, assign all old disks same order, put the new empty one in place of the missing (but now somehow "unassigned") one and tell it to trust parity as valid (which probably is), WILL it actually rebuild the missing disk? Or something somewhere, even though the parity is calculated for 11 data disks + parity, now "believes" the system should have 10 data disks + parity??? EDIT #2: I *MAY* have resolved this. I found an older 3TB disk (as the missing one) in my drawer. I followed the process described bv @JorgeB in the other thread... and while disk is not shown in dashboard as emulated - IT IS emulated (shows as not installed but does allow me to browse the emulated contents of the disk)... So, right now I am making a copy of the most vital data of that emulated disk to a USB disk. After that, I will actually "assign" that old 3TB disk back to the array to be re-built from parity. Then after parity syncs, I will replace the disks with the new ones I have on order (one by one to allow re-sync each time). Seems UNRAID, although scary at times, is more resilient than meets the eye.

OK clear. I still can only hope #1 gets "properly" implemented for disaster situations some time. In my case, I don't want to destroy my parity yet, as it is yet undetermined if the disk will recover, cloned or what.

Experts in the room: Is it possible to achieve #1 partially, by going to maintenance mode and then using unassigned devices to mount cache? (and not mount the other disks at all) Will I be able to then start some containers and vms? Also I think UD also allows to mount as read-only. Can I use that to access my remaining data without affecting parity?