Art4security

Had a look at shares, it's definitely changed a bit since last I looked at it 😅. I see that there appear to be warnings next to all the shares that deal with the array and not just the cache, hoping this has to do with no parity being in place.. I'm also going to upload a copy of most recent diagnostics here now if anyone cares to have a look for gotchas that could cause issue with parity sync. I think I'm ok but.. still feeling a little worried about starting a new parity sync. corridantower-diagnostics-20240824-1404.zip

Thank you both. I have to say I was incredibly surprised when I picked a somewhat random order for the disks and everything booted up without a hitch, especially on the newest OS version. I will go about parity rebuild tomorrow night. I do have a cache pool, and that is where the VMs reside. The cache is set to be moved to the array.. which is the main thing that worries me about invoking the mover.. I don't know if it will get moved to a different location, or will somehow scramble the array. Is that silly? I would have thought that the cache is periodically clearing itself and that boot up of the VMs would rely on the array in some way, but now I'm not so sure. I'm wondering if the VMs are ever really moved from the cache pool, or if they are statically linked to them making the move to array un-necessary/useless. I also have some data set to move to only certain disks. I'd be happy to do away with this and not segment the array at all, if it made any difference. Something told me that segmenting sections of the array would be better health wise for it, but I'm now wondering if it would be healthier overall to just let the mover utilize the entire array randomly. So far, I'm surprised to see that I haven't had anything that appeared to be missing at all data or functionality wise from the array. All data structures appear intact and retrievable. Some data migration operations invoked from the VMs seem to be a little slow but I could be imagining that. Since yesterday, I have been incrementally backing up manually to an external disk data that is crucial to operations. I don't mind buying new Windows licenses or redoing the dockers, I was only running a couple dockers and they likely needed major updates anyway. The box was truly built to be a only a file storage solution that could be accessed by two work stations simultaneously as VMs onboard. It has worked so well for the last five years I've grown farther and farther from needing to support it. It's last uptime check and disk swap (done back in January of this year) was I think after 3 yrs of solid use. During that swap I failed to backup after everything was running. I meant to after a period of stability, but let it go much too long and well... total blunder.

So another wrinkle.. I really failed. I failed to save the most recent flash backup to the array... it is lost. SO.. I have no way to rebuild the array exactly as it was.. that said, the array can be booted and it works without parity disks, so can I just rebuild the parity around the current config and crate a new backup from that? Will I lose anything? Seems like it should work but I'm worried the first time the mover is invoked it is going to completely bork the machine because disks are now in a different order.. is that silly?

Thank you sir! I am copying the backup folder now and will try restoring the config file portion to the USB tonight. You've been extremely helpful. Thank you!

Vr2lo you are the man! I assigned all the drives in random order, kept the parity drives unassigned and everything just booted, including my VMs!! I can't believe it actually works without restoring backups or anything! So now the question is, (after I've created a backup of the array files), how do I log about adding in the parity drives (I guess as new drives?) so I can get the array protected?

ah, so I should keep the parity drives separated out and assign all the disks to the array and start the array unprotected so I can mount a share and get the config folder? That sounds doable!

Thank you Vr2lo, ive mounted all disks (besides parity) and the backups show across all the drives. Once mounted, I don't know how to go about copying the /config folder over to the flash. I was hoping I could view the mounted drives via my laptop but no dice so far... Am I overthinking this?

Ok, so update: I got a new key flashed with the newest version of Unraid and I have a zip of 6.9.2 sitting in the wings. I've gotten the machine booted, and I've installed UD and mounted the drives but I still can't see them when I look at the server from my laptop.. I unfortunately do not know the proper order of drives in the array and I don't want to try starting the array since I feel like I will lose data possibly.. I think I know which drives were my parity drives (99% sure), so if I start the array with "parity is already valid" checked will it be able to tell me if I have the order of the other drives correct? I am reasonably sure I have most of the 7 drives in the right location, just 2 that are a total coin toss.. I think.. Man, this is turning into a bigger head scratcher than I thought and I am beginning to get worried that I REALLY blundered not having better backups. Any further help would be amazing folks.

Thank you both! This gives me some solid next steps to try and take care of the issue, and with any luck we will be back up and running later tonight. I will report back when I have gotten it live again. Thank you so much for your help!

Unraid server I built a number of years ago has been absolutely rock solid. I created a backup of the flash drive on the array just in case, but this was before the days of Unraid Connect.. wish I had stayed on the ball and gotten that worked out, will do this time if I can get it back but... Long story short, UPS attached to the server failed and after replacing it my flash drive is unreadable. I was running a very old version of Unraid (6.9.2 latest I can confirm), and I'm needing some help getting my license ported to a new drive and hopefully pulling the backup from the array (hoping it's there somehow, otherwise I will have to go off ancient screenshots to try to recreate the array).. I know I put myself and my parents in this spot, and I will do what research I can this week to try and make sure I do better next time, but anybody who can help me with next steps before I bite the bullet and pay for one-on-one time, I'd really appreciate it.

Had this set up on 1 server and did a few scans, it worked great. Went to set it up on another server and the webgui will not connect on either server now. Any suggestions or advice on how I can remedy this? Here is a copy of the log file from one of the servers. Setting user permissions... Modifying ID for nobody... Modifying ID for the users group... Adding nameservers to /etc/resolv.conf... Extracting packaged nessus debian package: Nessus 8.10.0... Changing owner and group of configuration files... Creating symbolic links... Cleaning up... Starting Nessus : . [Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-udp.db][fd=-1][map_sz=38575]: complete [Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete [Mon Aug 3 22:35:07 2020][29.1][op=qdb_sync][name=upgrades.db][fd=5][map_sz=0][file_size=55]: complete [Mon Aug 3 22:35:08 2020][29.23][sched=100][pid=22][plugin=nessusd_www_server6.nbin][instr=0xb4ba] : Error: Could not find function 0xf00001af call stack: ----------- [0b4ba:Saucer::Client.request+67] call, addr(0xf00001af), -, # ???? () [C func] [0d572:TelemetryService.submit+39] refcall, fp(1), string#629, # from: fp(1) [0d509:TelemetryService.sendStartupTelemetry+136] call, addr(0x800007), -, # TelemetryService.submit() [12c69:send_backend_starting_telemetry+5] refcall, fp(0), string#2935, # from: fp(0) [12c2d:main+18] call, addr(0x12c64), -, # send_backend_starting_telemetry() [2dd57:main+13298] call, addr(0x12c1b), -, # main() [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=22][plugin=nessusd_www_server6.nbin][instr=0x2a039] : Invalid index for hash table call stack: ----------- [2a039:utils::parseResponse+45] larray, r#26, fp(2), [0d575:TelemetryService.submit+42] call, addr(0x2a00c), -, # utils::parseResponse() [0d509:TelemetryService.sendStartupTelemetry+136] call, addr(0x800007), -, # TelemetryService.submit() [12c69:send_backend_starting_telemetry+5] refcall, fp(0), string#2935, # from: fp(0) [12c2d:main+18] call, addr(0x12c64), -, # send_backend_starting_telemetry() [2dd57:main+13298] call, addr(0x12c1b), -, # main() [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=51][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c call stack: ----------- [0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2) [217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2) [2dd58:main+13299] eop, -, -, [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=52][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c call stack: ----------- [0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2) [217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2) [2dd58:main+13299] eop, -, -, [Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=53][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c call stack: ----------- [0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func] [07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2) [217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2) [2dd58:main+13299] eop, -, -, [Mon Aug 3 22:35:25 2020][29.1][op=qdb_sync][name=plugins-desc.db][fd=22][map_sz=0][file_size=178979610]: complete [Mon Aug 3 22:35:25 2020][29.1][op=qdb_sync][name=plugins-code.db][fd=7][map_sz=0][file_size=2789806079]: complete [Mon Aug 3 22:35:45 2020][29.1][op=_qdb_map_lowmem][name=plugins-code.db.15964941251616699263][fd=7][map_sz=0][file_size=2789806079]: complete [Mon Aug 3 22:35:46 2020][29.1][op=_qdb_map_lowmem][name=plugins-desc.db.15964941451807749847][fd=19][map_sz=0][file_size=178979610]: complete