GMB44

Thanks for the quick reply and apologies for the basic question. I was unsure if the clear also sets the format and it has been many years since I have added a drive. It is now already added to the array after a quick format.

I recently upgraded my parity drive from a 10TB WB drive to a 20TB Seagate drive and the process completed fine and parity is valid. I then threw the old WB parity drive into a slot in the array and let it clear. When clear was finished after a day or so, Unraid said the disk was unmountable. Since parity on the array is valid on the new drive, I suppose I could format the old parity drive and clear again. Is there a quicker way to do this since the old drive appeared to already clear? I saw a few posts suggesting a system file check, but don't want to do anything without fully understanding the consequences first. Thanks for any help in advance. tower-diagnostics-20250424-0810.zip

Sadly the parity check returned millions of errors after only running though roughly 1% of the array. It is still running, but I am doing so without auto correcting. I am not sure where I went wrong in rebuilding everything. Once UFS Explorer found the missing files (using a different Windows machine), I moved them onto a spare drive (again, all done on a Windows machine separate from Unraid). I returned to my Unraid machine and formatted the unformatted disk to XFS. Then I mounted the spare drive using unassigned devices and moved the files from the spare drive to the newly formatted XFS drive. I also had one more ReiserFS drive to convert to XFS. I used midnight commander to move the files on that disk to a couple different disks until it was empty. Then I converted that to XFS. It is still empty, but all disks show up as XFS when mounted. I am sorry this continues to drag on. Should I continue running the non-correcting parity check? I attached diagnostics, but I am not sure if they are any help while parity check is still running. tower-diagnostics-20231205-2316.zip

Just wanted to say thanks again for the help. It appears everything has successfully transferred/formatted. I will run a parity check and should hopefully be back in business.

Thankfully UFS Explorer managed to find almost all the files on the corrupted disk. I am in the process of moving them onto a spare hard drive. First, thank you both for your patience and help. Second, what should be my next step once all the files are on a spare NTFS drive that I can mount on unraid? I already have disk 3 emptied from a few days ago and can format it to XFS. I could potentially start moving files onto that. I am not sure what to do with disk 2 (the corrupted disk) or how to ensure parity remains intact.

Apologies for the bump, but does anyone know if UFS Explorer is meant to be run on the Linux partition or the entire disk? Maybe it doesn’t matter, but I am hesitant to do anything that might hurt my chances of recovering data. As always, any help is greatly appreciated.

Ok I have the disk migrated to a new box and am about to scan with UFS Explorer Standard Recovery. Do I want to scan the Linux partition or the entire disk?

Not the news I wanted to hear, but thanks for all your help. I have many of the files saved on an external hard drive, but no clone of the disk that could act as a true backup. I wouldn’t even know where to begin in terms of which specific files were on the disk in question. If I were to try xfs recovery, which version do you think would best fit my scenario? Standard, access, raid, n raid? https://www.ufsexplorer.com/products/ Thanks again for your help.

Here are the results from the xfs repair: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock...found candidate secondary superblock... unable to verify superblock, continuing... this repeated a few more times, followed by: Sorry, could not find valid secondary superblock Exiting now. As I said earlier, I was originally able to format disk 2 to xfs and mount it, otherwise I assume I wouldn't have been able to move the files from disk 3 to it. My concern is disk 3 was close to full capacity. Is it possible this was part of the issue and the moving of files somehow corrupted disk 2? I am extremely grateful for any help I could continue to get on this. What is my next step, if any? I attached the diagnostics from maintenance mode and after running xfs repair, in case that is helpful. tower-diagnostics-20231201-1638.zip

So just to be clear, I should run it without any options in the check field? If so, I will cancel and restart without the -nv

I really appreciate the quick reply, as I am obviously concerned I just nuked a bunch of my data. I am running xfs repair -nv in maintenance mode now on disk 2 and will post results when done. So far, this is all they repair is saying: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock.. I was able to see disk2 mounted as xfs originally, which is how I was able to move all the files from the reiserfs disk3 to disk2. Will I potentially be able to recover this data (it was moved and not copied) if the disk cannot be recognized as xfs?

I am in the process of converting my old reiserfs disks to xfs. I checked parity prior to starting this process and all was good. I disabled VMs and Docker and made sure the mover was not scheduled. Since I had one drive already formatted in xfs (disk 6), I used unbalancer to move files off a reiserfs disk and onto the xfs disk 6. I repeated this process down the line, moving files off the next biggest reiserfs disk and onto the newly converted xfs disk. The first couple disk conversions (disk 1 and 4) went as planned after formatting. Doing the same process with disk 2, it initially appeared to work fine and was formatted into xfs after clearing. I then began to move the files on disk 3 to disk 2, which completed as expected. When I shut down the array to format disk 3 to xfs and started the array up again, I noticed disk 2 was also coming up as unmountable. I did not format either disk 2 (for a second time) or 3 once I noticed this was an issue. I changed the format of disk 3 back to reiserfs so it would mount, but nothing was ever formatted. I have read a few posts on xfs repair, but am checking for the best route forward. Is this an issue of the disk being too close to capacity? I also updated from Unraid 6.12.4 to 6.12.5 in between disks being moved (not during unbalancer running), but not sure if that is an issue. Any help would be greatly appreciated. tower-diagnostics-20231201-0850.zip

I have had a dual-boot, NVMe passthrough Windows VM (following SpaceInvader One's instructions) that ran fine for years. Recently I upgraded to Unraid 6.12.4. I had a few SMB issues with that version, so I rolled back to 6.11.5. This appeared to break the Windows VM. I could log into Unraid fine, but any time I would start up the VM, the screen would go black. So I wiped the USB drive and started a fresh 6.12.4 boot and rebuilt the windows VM. The data array was never changed in the process. With the new build, I am now able to connect to the windows VM and see it on my screen for a few seconds (or sometimes a minute or so). The screen may flash white once or twice before coming back, but then the screen eventually loses its connection to the VM. I am admittedly in over my head in reading the syslog, but this appears to be the error that is happening after starting the VM: Tower root: Error response from daemon: network di-6ba07cea1c77 is already using parent interface br0 The following error also repeats itself several times, but I believe this is before the VM is started (and I am not having any problems with the Unraid GUI as far as I can tell): ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.PRT0._GTF.DSSP], AE_NOT_FOUND (20220331/psargs-330) Google searches of these error messages haven't helped me much. I would be eternally grateful if someone could take a peek at the syslog file to see if there is anything simple I am missing. I feel as though this is a passthrough issue, but have tried everything I can think of from watching SpaceInvader's videos. Thanks in advance. syslog.txt