NIronwolf

Went to update to the new plugin. Somethings not pointing to the right place it seems. Getting a Network failure. I'd guess the .plg files are hosted the same place the list comes from, but that's probably not the case if it's not downloading. plugin: installing: unbalanced.plg Executing hook script: pre_plugin_checks plugin: downloading: unbalanced.plg ... plugin: unbalanced.plg download failure: Network failure Executing hook script: gui_search_post_hook.sh Executing hook script: post_plugin_checks

Rebuild and scrub completed. All looks good. Thanks again for your guidance JorgeB!

Oh, here's a diagnostic grabbed while it's starting all that work. If all goes normally I can say it's rebuilt in like 36 hours. Probably don't need to look at this diag unless something more goes haywire. Thank you for your assistance JorgeB! reality-diagnostics-20230111-1150.zip

Oh, and the 4 drives that are setup btrfs aren't connected that way. I'd guess any corruption there would have been from the system locking up and having to hard power it off. Ok, this time all the disks mounted normally and show they're xfs. (With the disk that dropped being rebuilt.) Running that scrub on my scratch cache drives now. I guess it just needed me to tattle on it to do what it normally does when I have to reset a drive.

Memory checked fine (as I suspected it would). The errors are the flakey connection to my external drive enclosure over eSATA I believe.

I don't know how to make a backup of the LUKS headers. (I recognize the word though and that worries me greatly.) The btrfs is only for one of the cache pools. I use ext4 on all the array drives (encrypted).

First, I realize I have a flakey port replicator or something. It can sometimes drop a drive. I had a drive drop from the array. I took a diagnostic and then rebooted. Then took a second diagnostic. I toggled the drive to empty then back to the original drive. I've done this in the past and it just rebuilt and everything was fine. However, today ALL the disks say "Unmountable: Volume not encrypted". I'm worried it already killed everything as it auto started the rebuild, but I hit stop right away. No it's trying to Stop the array but not finishing. It's reporting the drive activity is 0, but the status at the bottoms says "Array Stopping • Retry unmounting disk share(s).." Have I just corrupted everything? reality-diagnostics-20230111-0735.zip reality-diagnostics-20230111-0841.zip

Ah! I see there's at least a partial directory of things here. I zipped it up, I'm not familiar enough to know what's missing though. tower-diagnostics-20221014-1957.zip

I tried running the update from the WebGUI again and the web server doesn't start. If I SSH in it logs in and I look around a bit. But when I run "diagnostics" to make a package I get this error. Warning: parse_ini_file(/var/local/emhttp/var.ini): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 313 That var.ini file doesn't exist. So I can't even get a diagnostic on the updated version. Is there a key set of files I can manually try to copy out? It's my email server so I'll be downgrading again, but can go through an upgrade again later.

Here is the full diagnostic. (Occasionally, one of the port replicators won't fire up correctly from a cold boot and I just do a restart and then it's happy.) reality-diagnostics-20221014-0859.zip

Ok. Did the downgrade to 6.10.3. Happy to entertain ideas why the web server isn't loading on 6.11.1.

Recopied out the bz* files from the 6.11.1 down load. It's not making a web server. root@REALITY:~# netstat -plnt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 1419/wsdd2 tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 1419/wsdd2 tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1404/smbd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1404/smbd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 7820/sshd: /usr/sbi tcp6 0 0 :::445 :::* LISTEN 1404/smbd tcp6 0 0 :::139 :::* LISTEN 1404/smbd tcp6 0 0 :::22 :::* LISTEN 7820/sshd: /usr/sbi

I'm not positive at this point. It may have been marked disabled when started in maintenance. I've been having issues with my external port replicating enclosures so I may just be headed for a big crash. I'm finding some bulky files with recognizable names. I'm hoping that I can find a decent backup of my appdata stuff, but I usually take that on the 1st of the month so... yeah. And ofc it's on the array instead of a separate system so worried about the reliability of that.

I'm hoping someone has any sliver of decent news about my situation. I had a drive halt and it stopped the array. When I rebooted it came up as a bad file system so I stopped it and restarted in maintenance mode so that I could run the xfs_repair check from it's settings page. The repair finished and I was then able to get the array to start up again. I set about seeing what had happened on the drive and now I'm faced with 10s of thousands of numbered files in my 'lost+found' directory. There are a few directories, but a huge amount of this drive was various appdata subdirectories and that means I have no idea where these files belong even when I have a directory listing of filenames. I guess I'm just looking for confirmation that I'm completely hosed. Thanks.