clay_statue

FOR FUTURE THREAD HUNTERS AND INTREPID PROBLEM SOLVERS... THIS HAS BEEN SOLVED As JorgeB suggested there were VM's autostarting, but I couldn't get to the VM screen to turn them off before it would freeze up. To remedy autostarting from CLI (within /mnt/user/domains): $mv yourVM/yourdisk.img disabled_yourVM/yourdisk.img This didn't solve the problem but it may solve yours. What was ACTUALLY my PROBLEM was that the system/libvirt/libvirt.img file must've been bad. I deleted it from the advanced settings in VM Manager and now I need to rebuild all my VM xml files BUT it solved my problem! I can now enable VM services without immediately borking my server. At least this gives me a point to rebuild from vs being entirely unable to even interface with the server because it starts screaming as soon as I enable VM Manager LESSON BEING CRITICAL BACKUPS FOR SERVICES -- APPDATA DOMAINS SYSTEM My previous backup method of an external usb drive which got disabled because it was unplugged when the server was moved briefly to change the attic air filter so my backups are too far out of date to be useful. New server will have raidz pools in cache so I can snapshot everything to the array and also rsync it to somewhere else.

Whenever I enable the VM manager in settings my CPU cores will spike and the system will freeze requiring an unclean shutdown to escape from it. I was eventually able to disable the auto start (by editing config/disk.cfg on the flash drive) which allowed me to access the VM manager and shut that down too. If I turn it on then it just grinds to a halt. How did I get here? I had some drive failure issues on my elderly server. The cache with appdata and domain decided it had no data on it. Despite the drive showing healthy and indicating it was full of data, searching it from the CLI revealed it to be empty. Also the parity drive quit within a few days of that. Since the old server was circa 2010 it was time for a new build so I put a new mobo in a new case and I'm trying to rebuild everything. I plugged the offending cache into a different computer and saw my data was still there so I was able to recover it and I tried to move it back into the user shares via the cli. Later I got into file tree hell in the appdata and added the ssd back to a new pool and the array could see the data again in the new system so I let the mover finish it off. I've already let the mover put the system and domain shares onto the new zfs cache pools so I don't think it's slow array speeds causing the freezing or the cpu cores spiking PLS HALP - I need services from unraid fractaltower-diagnostics-20241026-1828.zip

I stopped everything dead silent and watched the disk activity and it was nil. So I tried restarting the data rebuild and it's chugging along at 20 MB/s which will get the job done 3 days which is an acceptable timeline. I realize I might have borked it by running the unbalance to move the data off initially and was seeking wise council from the forum of elders. I hope it'll be fine. Thanks for your attention towards it.

Yes, sorry somehow I am confused too. My topic got mixed up with another user with a similar issue and somehow they're both titled the same. My diagnostics are above but I'll put them here again. fractaltower-diagnostics-20240110-1843.zip

May I ask which part of the diagnostics revealed this information? I am suffering incredibly slow data rebuild speeds and I'm looking for clues as to why. Pls help....

This is sub-optimal. Most of the data on the recently emulated 6TB disk is just accumulated media that I don't care about but I have about 2.5TB of data (mostly movies of my dogs as puppies) that isn't critical but I'd highly prefer to keep it. I did a quick SMART test on the drive and it seems okay. Originally tried unbalance to remove data off the drive to another on the array that is mostly empty but the speeds on that were also very slow (2.5 MB/s). SO I am now trying to rebuild the disk but it's even slower! Why is my data only moving at a trickle? I would prefer to shorten the timeline on recovering this drive from six months down to a day or two if possible. fractaltower-diagnostics-20240110-1843.zip

I've restored previous version 6.9.x since that was what I upgraded from. I'm going to hold steady here at this version for a minute and make sure everything is copacetic before venturing into 6.10.x. Maybe 6.12.x will be released in the meanwhile and the bug will be contained to the previous version so i can leapfrog right over it.

Was digging around and found this warning in the syslog from when it was booting... ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block:

Here's the syslog file and the last entries. I deliberately cancelled the parity to see if it would crash, which it did a few minutes later. Nov 14 10:26:12 FractalTower kernel: docker0: port 1(veth440e05a) entered disabled state Nov 14 10:38:40 FractalTower kernel: docker0: port 1(vethb74e54b) entered blocking state Nov 14 10:38:40 FractalTower kernel: docker0: port 1(vethb74e54b) entered disabled state Nov 14 10:38:40 FractalTower kernel: device vethb74e54b entered promiscuous mode Nov 14 10:38:40 FractalTower kernel: eth0: renamed from veth6b04af4 Nov 14 10:38:40 FractalTower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb74e54b: link becomes ready Nov 14 10:38:40 FractalTower kernel: docker0: port 1(vethb74e54b) entered blocking state Nov 14 10:38:40 FractalTower kernel: docker0: port 1(vethb74e54b) entered forwarding state Nov 14 10:40:38 FractalTower kernel: mdcmd (37): nocheck cancel Nov 14 10:40:38 FractalTower kernel: md: recovery thread: exit status: -4 syslog.txt

So this is a repeatable error. Within five minutes of parity completing (or being cancelled) unraid crashes itself. Total shutdown. I started mirroring syslog to flash and attached the file below. Please help! I cannot see what is causing the problem. Should I downgrade back to 6.10? fractaltower-diagnostics-20221114-1020.zip

Sorry, meant to say that I'm getting an "Internal Server Error" when I try to access the webgui. This is the same whether trying to access remotely or natively from within the lan direct with the IP address, so I doubt it's a NGINX proxy issue.

This started happening today. I tried rolling back to the previous docker image tag. I cannot see any obvious problem in the nextcloud logs. Really at a loss here. It's been rock solid basically since I originally installed it. Any thoughts would be appreciated.

This started happening today. I tried rolling back to the previous docker image tag. I cannot see any obvious problem in the nextcloud logs. Really at a loss here. It's been rock solid basically since I originally installed it. Any thoughts would be appreciated.

Is this because the default sata/sas ports available in the tower aren't usable by the unraid array? I was looking at the HP ProLiant m350 and the unraid thread about that one said that the native raid controller didn't work with unraid and you needed to basically make use of the pci-e slots to connect sata drives and bypass the raid controller Additionally I see that the card you are talking about only has two SAS ports internally. I am unfamiliar with SAS... how many drives can you run off that one card? Just two?

I cannot access shares on unraid from my windows laptop. I have "remote access to LAN" and indeed my laptop can ping my unraid server and my router, so I do indeed have connection to devices on my LAN. I can also access my dockers webGUI's. The wireguard connection is working in every way *except* I cannot access my shares. Even if I type the network address into file explorer \\x.x.x.x\share it cannot access the share. I tried setting tunnels both with specified NAT port forwarding and going UPnP alternatively. No dice. Before OpenVPN was deprecated I was using it as a docker image and was able to get remote access to my shares no problem... so I dunno what's going on here? [SOLVED] Had to stop the array and add the wireguard network pool to Settings > Network Services > SMB > hosts allow = 10.253.0.0/24 After I did that I could manually enter \\serverip\share in File Explorer and then map the drive. Big success!