Vagabond

I read the initial PDF and searched this topic, but could not determine if Dynamix move and copy operations include binary verification of successful writes - can anyone confirm? In Windows I usually use the verify switch to enable this, but moving files between disk shares using this tool would be so much more efficient.

Thanks for the feedback. I decided to move my old RAID card to the rebuilt machine rather than deal with the renaming issue. Everything appears as normal now and I was able to bring the array online. I was having some unexplained shutdowns in the previous unit, which is why the hardware swap. As long as the RAID card wasn't the culprit I should be ok. I'm going to run a parity check now so I should know in 36 hours.

I am moving my 14 disk array on Unraid Pro 6.12.4 to different hardware. I took a picture of my configuration before tearing down the old setup, and after moving my USB stick and booting up the new setup, 6 disks were identified fine with green ball (presumably the ones on the motherboard SATA ports) while the other 8 were showing "missing" initially. I matched each slot with the correct disk from Unassigned Devices, but now each reads "wrong" and I cannot start the array due to "too many wrong and/or missing disks". It does look like the expansion card is assigning a different naming convention, but one can see by the serial numbers that everything matches. What's my next step in this case? Thanks!

Thanks, that upgrade procedure worked smoothly, and I performed an xfs repair on each data drive with no errors found. The original folder I was having problems with is viewable in Windows with no problems, so all's well that ends well, and I am upgraded as a bonus. Thanks for your help on this and guiding me through it.

I've been researching how to upgrade and would like some advice. I tried the instructions here https://docs.unraid.net/unraid-os/manual/upgrade-instructions/, but when I try to update the 'unRAID Server OS' plugin to the suggested 6.5.3, the installation fails as https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.5.3-x86_64.zip is no longer valid. I then tried manually installing the plug-in as suggested in the docs by pasting in the hyperlink https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg but I get an error saying "not installing older version". I did map to the Flash share and copied everything to an alternate location as a backup. It looks like the earliest available download is Unraid 6.10.3. Would I be best to use the manual installation method to install that over top of my existing flash drive, and then use the GUI to update to 6.12.4, or just go straight to 6.12.4? Thanks for your help!

Oh, one more thing before I run repair on all the data drives. In researching this question a bit before posting, I found a YouTube video by SpaceInvader One where he recommends unRAID 6.7.0 or higher due to needing xfsprogs v4.20.0 as older versions had issues. Is this something I need to be concerned about?

I was wondering about that too, but judging by the SMART hours on the disk at least, there is no immediate pattern. Unless, and you might be onto something, one group or the other has been swapped into the array since I went to 6.3.5 from an older version of unRAID. I didn't always have 14x10TB but swapped them in place of smaller drives over time.

I have been using unRAID for a number of years and for the most part everything has been going great, so kudos to the team! I will put a longer description below, but my question has to do with xfs repair -n. I have 14 drives in my array where one is parity, and all are 10TB Western Digital. In running xfs repair -n on all of them, I notice that 5 of the disks do not enumerate the number of inodes, but the other 8 do. I thought maybe the difference was that 8 of the disks are on an HBA, but that is not it. One HBA disk has no values listed, and one motherboard disk does. This is the difference I am referring to (I will also attach a sample output of each): - scan filesystem freespace and inode maps... - 11:37:28: scanning filesystem freespace - 20 of 20 allocation groups done - found root inode chunk - 11:37:57: process known inodes and inode discovery - 472640 of 472640 inodes done - process newly discovered inodes... vs - scan filesystem freespace and inode maps... - found root inode chunk - process newly discovered inodes... The array starts ok, quick SMART test on each drive passes, and parity check finished with zero errors, I'm just wondering why there is a reporting difference, and whether there are any additional checks I should perform. Thanks! History ======= I was recently having trouble viewing the directory listing in Windows for one folder on my 6.3.5 server, in that Windows Explorer was non-responsive. I decided to go to the unRAID GUI and drill down to see which drives contained contents for that folder. Anyway, the GUI then became non-responsive, so I decided to power down the server and bring it back up. I think my Putty command to powerdown was not successful but one way or the other the server had an unclean shutdown. I decided to try running xfs repair on the data drives as a precaution.xfs_sample_run_with-n_2.txtxfs_sample_run_with-n.txt

Method 1 also failed for me from 5.0.6. Received error: "Boot error" Removed USB stick, plugged in on Windows 10 machine, ran make_bootable.bat, replaced in UnRaid box Booted up ok.