alexfsr

Alright, ive started the array rebuild without parity 2. Im guessing i'll have to indeed clear it out before re-adding it as Parity 2 in order to match Parity 1's configuration (4k-alligned). Disk 4 is now showing 4k-alligned system as well. Thanks for the help!

Removing Parity 2 disk allows the array to start but gives warning that all data on disk 4 will be overriden. Is that ok? Also should i start the array in Maintenance mode? Help page you linked earlier says it speeds up the process. Also are you sure the rebuild of disk 4 will make it 4k-alligned? All other data drives are also 1MB-alligned like Parity 2.

Ok this diag is after Parity 2 was unassigned and re-assigned, without starting the array (still unable). nexus-diagnostics-20260710-2143.zip Also, looking into the array drives, it appears all drives except for Parity 1 are using 1-Mb alligned GPT. Which is probably what causes the issue, but why now? How did it work fine for 1 year up until now with 0 issues?

Updated the server to latest version. Still cannot start the array. Do i need to start the array without disk 4 again to provide good diags?

The problem is i cannot start the array in this configuration. When i re-assign the drives to their original assignements, it gives an error that Parity drive is not biggest. The content of disk 4 does otherwise look correct, yes.

Ok, here it is. I hope mounting it normally doesnt let apps and dockers to start messing with it. nexus-diagnostics-20260710-2025.zip

Started in Maintenance Mode. nexus-diagnostics-20260710-1335.zip

Upon further inspection, it seems drives sdc and sdh may have somehow switched places in UnRaid. Drive sdh appears to have the same FS size parameters as Parity drive sdf. But curiosly, mounting drive sdh via UD shows it to have the expected data drive contents, while drive sdc is unmountable (as i would expect from the parity drive - my understanding is that the parity drives hold raw bit data for doing the bitwise parity math with the other drives in the array). How can one resolve this situation??

Hi all, Today i went to check up on my Unraid media server and i was greeted with an array showing 1 (of 2) parity drive and 1 data drive as disabled. The server itself seems fine and all drives short SMART report came out clean so i rebooted the server, hoping it would clear up. Unfortunately, things got worse - the missing data drive came back showing as "new disk" and the parity drive continues to be disabled for no apparent reason. Removing the data drive from the array and mounting it with UD works fine, all of its content seems to be there and accessible. But for some reason Unraid is reading it as a new replacement drive. Furthermore, the parity drive's file system seems to have shifted and now it no longer reads the same size as the other parity drive that is still working. As a result, the array cannot be started: Indeed looking at the logs of the server, the second parity drive (sdc) now shows FS starting at sector 2048 like a data drive, as opposed to sector 64 like Parity disk 1 (sdf). Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdf 2>&1 Jul 9 16:12:22 Nexus emhttpd: disk sdf 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sdf1 64 10000831299072 Jul 9 16:12:22 Nexus emhttpd: device sdf partition: sdf1 type: gpt start: 64 size: 9766436812, code: 0xee (3) Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdd 2>&1 Jul 9 16:12:22 Nexus kernel: mdcmd (1): import 0 sdf 64 9766436812 0 HGST_HUH721010ALE600_7PG5JY9R Jul 9 16:12:22 Nexus kernel: md: import disk0: (sdf) HGST_HUH721010ALE600_7PG5JY9R size: 9766436812 Jul 9 16:12:22 Nexus emhttpd: disk sdd 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sdd1 2048 10000830283264 Jul 9 16:12:22 Nexus emhttpd: device sdd partition: sdd1 type: gpt start: 2048 size: 9766435820, code: 0xee (5) Jul 9 16:12:22 Nexus kernel: mdcmd (2): import 1 sdd 2048 9766435820 0 HGST_HUH721010ALE600_7PG5JA6R Jul 9 16:12:22 Nexus kernel: md: import disk1: (sdd) HGST_HUH721010ALE600_7PG5JA6R size: 9766435820 Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sde 2>&1 Jul 9 16:12:22 Nexus emhttpd: disk sde 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sde1 2048 10000830283264 Jul 9 16:12:22 Nexus emhttpd: device sde partition: sde1 type: gpt start: 2048 size: 9766435820, code: 0xee (5) Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdg 2>&1 Jul 9 16:12:22 Nexus kernel: mdcmd (3): import 2 sde 2048 9766435820 0 HGST_HUH721010ALE600_7PG5LEDR Jul 9 16:12:22 Nexus kernel: md: import disk2: (sde) HGST_HUH721010ALE600_7PG5LEDR size: 9766435820 Jul 9 16:12:22 Nexus emhttpd: disk sdg 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sdg1 2048 10000830283264 Jul 9 16:12:22 Nexus emhttpd: device sdg partition: sdg1 type: gpt start: 2048 size: 9766435820, code: 0xee (5) Jul 9 16:12:22 Nexus kernel: mdcmd (4): import 3 sdg 2048 9766435820 0 HGST_HUH721010ALE600_7PG5MT8R Jul 9 16:12:22 Nexus kernel: md: import disk3: (sdg) HGST_HUH721010ALE600_7PG5MT8R size: 9766435820 Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdh 2>&1 Jul 9 16:12:22 Nexus emhttpd: disk sdh 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sdh1 2048 10000830283264 Jul 9 16:12:22 Nexus emhttpd: device sdh partition: sdh1 type: gpt start: 2048 size: 9766435820, code: 0xee (5) Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdi 2>&1 Jul 9 16:12:22 Nexus reload_services: execute queued job 3 Jul 9 16:12:22 Nexus kernel: mdcmd (5): import 4 sdh 64 9766436812 0 HGST_HUH721010ALE600_7PG5LVMR Jul 9 16:12:22 Nexus kernel: md: import disk4: (sdh) HGST_HUH721010ALE600_7PG5LVMR size: 9766436812 Jul 9 16:12:22 Nexus kernel: md: import_slot: 4 replaced Jul 9 16:12:22 Nexus emhttpd: disk sdi 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sdi1 2048 10000830283264 Jul 9 16:12:22 Nexus emhttpd: device sdi partition: sdi1 type: gpt start: 2048 size: 9766435820, code: 0xee (5) Jul 9 16:12:22 Nexus kernel: mdcmd (6): import 5 sdi 2048 9766435820 0 HGST_HUH721010ALE600_7PG5KVYR Jul 9 16:12:22 Nexus kernel: md: import disk5: (sdi) HGST_HUH721010ALE600_7PG5KVYR size: 9766435820 Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdb 2>&1 Jul 9 16:12:22 Nexus emhttpd: disk sdb 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sdb1 2048 10000830283264 Jul 9 16:12:22 Nexus emhttpd: device sdb partition: sdb1 type: gpt start: 2048 size: 9766435820, code: 0xee (5) Jul 9 16:12:22 Nexus kernel: mdcmd (7): import 6 sdb 2048 9766435820 0 HGST_HUH721010ALE600_7PG5LX3R Jul 9 16:12:22 Nexus kernel: md: import disk6: (sdb) HGST_HUH721010ALE600_7PG5LX3R size: 9766435820 Jul 9 16:12:22 Nexus emhttpd: /bin/lsblk -lnbo TYPE,NAME,START,SIZE /dev/sdc 2>&1 Jul 9 16:12:22 Nexus emhttpd: disk sdc 10000831348736 Jul 9 16:12:22 Nexus emhttpd: part sdc1 2048 10000830283264 Jul 9 16:12:22 Nexus emhttpd: device sdc partition: sdc1 type: gpt start: 2048 size: 9766435820, code: 0xee (5) Jul 9 16:12:22 Nexus kernel: mdcmd (30): import 29 sdc 2048 9766435820 0 HGST_HUH721010ALE600_7PG5JL3R Jul 9 16:12:22 Nexus kernel: md: import disk29: (sdc) HGST_HUH721010ALE600_7PG5JL3R size: 9766435820 Now here's the real pickle: How do i recover this array without losing any data? Removing the parity 2 drive assignment causes a notification to pop-up that upon start of the array the missing data drive will be overriden (im guessing it's going to try to rebuild it?) Im currently running a full SMART check on Parity drive 2 (sdc), it's taking a long while. But i dont feel like it's going to reveal anything more than the short SMART check. To me it looks like a corrupted array config rather than failed drives. Any ideas? Attached is the diag zip for further info. nexus-diagnostics-20260709-2138.zip

Indeed i have figured out what's going on. You are correct, http://IPAddr works. The reason it wasn't working before was because i never write the http part, just the IP address in the browser field. Coincidentally, i remembered that Chromium based browsers started defaulting awhile back to https unless specified (and my server indeed doesn't have SSL because i could never figure out how to set it up properly. It never worked and caused the server to become completely inaccessible when i last tried to enable it with self-signed/generated SSL). Thank you!

Ok I tried to boot a fresh image of UNRAID configured from the disk imager with the same network settings (static IP, same IP as the original one). The fresh install was again refusing the connection when accessing via the IP address but it worked with "http://tower.local". After i setup a password and got to the main screen, i tried accessing the server with the IP address and it worked. I then went back and booted my orignal flash drive and that one also allowed the connection to the WebGUI via the .local domain. But it still refuses connections when using the IP address. What's going on? Seems to be something with the networking configuration but i don't see anything wrong with it and it hasn't changed since the last time i worked on the server and using the IP to access the WebGUI worked fine. I'll update everything now to see if it fixes but i really don't understand what's going wrong. EDIT: Running lastest stable verion of UNRAID now, all plugins updated. Docker and VM manager disabled. Still no access via IP.

Ok. That's not gonna mess up the HDD array, right?

I have never used the local domain nome to access the server, only IP (static). I don't believe my router is configured for it to work either but i can try it now. It's serverName.local , right?

Hi, I've been using UnRAID for a few years now for my family's NAS and Plex Server (docker). A while back, I also hosted a Windows 10 VM for my mom to use when she does her arts and craft (the server lives in the same room and it has more than enough power to handle light browsing and zoom calls). It has been working fine for a while but the Windows VM started having issues with the GPU recently (driver time out) so i decided to investigate during Christmas break. However, when i went to login to the server, i was faced with a "Connection Refused" error message. The server continues to work just fine as a NAS, all shares are accessible on the network. SSH works as well. But the webGUI is dead for no appearant reason. So far i have tried: Safe mode - No change. Renamed the virtual disk file for the VM to stop it from auto-starting on boot (i couldn't figure out how to stop it with virsh) - VM doesnt start anymore but GUI still missing. Changed the USB port of the boot flash drive. Checked the flash drive on another PC. It reads fine and seems to have all the server files on it as normal. Checked via local terminal with df command - the flash drive seems to properly mount at /boot. Generated a diagnostic zip with the command from local terminal - successfully saved to the flash drive and attached to this post. I don't know what else to do. This server hold a sh*t load of family data and I need to restore it ASAP but i have no idea what's wrong with it. Everything seems to be fine and works fine except for the web GUI. Any ideas? homenas-diagnostics-20230107-1825.zip