gooner_47

Following this thread a parity check has been run, finding 130 errors. What steps do I need to take here? Thanks

Bloody gigabyte board! Took me forever to find this setting - because the first time I got into the BIOS it wasn't even visible! I had to go into "Dual BIOS/Q-Flash Utility", changed some settings in there, rebooted, and then the options available to me in the advanced bios screen changed and showed the "Backup BIOS Image to HDD" I wanted. You can see one screenshot of the advanced screen has fewer options, and then a later one more magically appear! Can't wait to build a new server and get rid of this hardware. Anyway, error is now gone and the array is started again. Just wanted to say thanks for your help, and I've attached the screenshots of the BIOS settings in case it's useful to others in future. IMG_7546.HEIC IMG_7554.HEIC IMG_7555.HEIC IMG_7557.HEIC IMG_7565.HEIC

Interesting, thanks for confirming. I definitely remember checking for this before and I'm sure I disabled it, but it's been years so it's hazy. I will re-check the BIOS.

I didn’t this time, partly because it involves first getting up in the loft to dig out the wired keyboard and spare monitor, then going down into the crawl space under the house to get to the server. But also because after reviewing those hdparm commands, I seem to remember I had this previously years ago and disabled the BIOS feature then. Is it possible for this to re-enable itself? If so I will make the time to get down to the server and explore the BIOS again.

The hdparm guide in the thread you linked gives "The page you requested does not exist" so I searched and found some other examples in previous posts. I ran hdparm -N /dev/sdb which gave: /dev/sdb: max sectors = 39063648191/39063650304, HPA is enabled I then ran hdparm -N p39063650304 /dev/sdb which gave: /dev/sdb: setting max visible sectors to 39063650304 (permanent) max sectors = 39063650304/39063650304, HPA is disabled I then ran the wrong command on the other drives. (I'm sleep deprived with a newborn baby). I was setting the HPA values on the other drives by mistake. Here's the commands I ran and the hdparm checks on the drives after I realised the fuckup. The max sectors seem to look correct but I'm sure I've fucked up a setting somewhere, diagnostics are attached. What do I need to run to unfuck what I did? root@Nebula:~# hdparm -N p39063650304 /dev/sdb /dev/sdb: setting max visible sectors to 39063650304 (permanent) max sectors = 39063650304/39063650304, HPA is disabled root@Nebula:~# hdparm -N p39063650304 /dev/sdd /dev/sdd: setting max visible sectors to 39063650304 (permanent) SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 01 21 04 00 00 a0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 11721045168/11721045168, HPA is disabled root@Nebula:~# hdparm -N p39063650304 /dev/sde /dev/sde: setting max visible sectors to 39063650304 (permanent) SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 50 01 21 04 00 00 a0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 7814037168/7814037168, HPA is disabled root@Nebula:~# hdparm -N p39063650304 /dev/sdf /dev/sdf: setting max visible sectors to 39063650304 (permanent) SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 01 21 04 00 00 a0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 11721045168/1(18446744072545694896?), HPA setting seems invalid (buggy kernel device driver?) root@Nebula:~# hdparm -N p39063650304 /dev/sdc /dev/sdc: setting max visible sectors to 39063650304 (permanent) SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 50 01 21 04 00 00 a0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 976773168/976773168, HPA is disabled root@Nebula:~# hdparm -N p39063650304 /dev/sda /dev/sda: setting max visible sectors to 39063650304 (permanent) SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 0/1, HPA is enabled root@Nebula:~# hdparm -N /dev/sdb /dev/sdb: max sectors = 39063650304/39063650304, HPA is disabled root@Nebula:~# hdparm -N /dev/sdd /dev/sdd: max sectors = 11721045168/11721045168, HPA is disabled root@Nebula:~# hdparm -N /dev/sde /dev/sde: max sectors = 7814037168/7814037168, HPA is disabled root@Nebula:~# hdparm -N /dev/sdf /dev/sdf: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 11721045168/1(18446744072545694896?), HPA setting seems invalid (buggy kernel device driver?) root@Nebula:~# hdparm -N /dev/sdc /dev/sdc: max sectors = 976773168/976773168, HPA is disabled root@Nebula:~# hdparm -N /dev/sda /dev/sda: SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 14 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 1159924272/1(120265081255028?), HPA setting seems invalid (buggy kernel device driver?) The same message is present on the parity drive also after a restart. nebula-diagnostics-20250629-0931.zip

Thank you, I will do this. Would disabling and removing HPA be the only steps required to prevent this message?

Diagnostics attached nebula-diagnostics-20250624-1644.zip

Hi, we had a brief blip in power the other night and the next day I noticed the server wasn't responding. When I log into the admin console I see the following message next to the parity drive (also says "wrong"), and the array is not started: "All existing data on this device will be OVERWRITTEN when array is Started". Please advise best course of action to resolve this. I'm hoping parity does not need to be rebuilt.

Noticed 3 parity errors in one of the checks. Ran it a second time just to see if it was a one off occurence, but got the same 3 errors again. Ran it a third time with "Write corrections" checked but although during the check it said something along the lines of "Corrected 3 errors" (can't remember the exact wording now), it has finished with 3 errors again: nebula-diagnostics-20230609-0717.zip

This is a Robocopy issue. Ran the following command and all was fine, the destination folder didn't "disappear". Key part is the "/A-:SH" flag at the end. robocopy /E /R:5 /W:2 "D:" "\\NEBULA\Backups\FiLaptop\New 06-01-2023" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" /A-:SH Stackoverflow post Blog post with the solution to "unhide" the folder again, and the flag to add to robocopy command to prevent this happening in the first place

So as a new server won't be on the cards for a while, I stopped all the docker containers, turned off autostart and rebooted in the hope this would help with any memory issues for the purposes of the diagnostics. I've managed to recreate the issue: Manually create an "06-01-2023" folder on the server, from within windows file explorer (in case the problem was folders created by Robocopy itself) Start robocopy running with robocopy /E /R:5 /W:2 "D:" "\\NEBULA\Backups\FiLaptop\06-01-2023" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" Click in the command prompt to pause robocopy after a few minutes Open file explorer and finder, in both the "06-01-2023" folder is not visible However, entering the path manually in explorer does then display the contents of the folder Out of curiosity I then tried manually typing out the folder name "04-01-2023" from the original post where I first saw the behaviour and all of the contents were then displayed To test this the other way, I created a "Test" folder within finder on the mac, and that was immediately visible on both machines: So then I created another, empty folder on the Windows machine, closed explorer and reopened it and it was visible on both machines So then I started wondering if it was robocopy copying files into that directory that was "hiding" it Ran the following robocopy /E /R:5 /W:2 "D:" "\\NEBULA\Backups\Test created by the windows machine" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" The icon for the directory then changed to indicate it was a hidden item (paler) Sure enough the next time I reloaded file explorer it was gone SO after all that debugging, it looks like the problem is that the result of running robocopy on a directory on the server, is to hide it from view on both windows and mac. Diagnostics here nebula-diagnostics-20230106-0710.zip At this point I'm not sure if this a robocopy "feature", or an Unraid issue. What do you think, is this something that warrants further investigation? I will do some more searching to see if others have encountered the same behaviour with robocopy - unraid or not.

Yeah. A new server is in the works. Is that what's caused this then?

nebula-diagnostics-20230105-1416.zip

Ran a robocopy command on a windows laptop to copy some files and directories to the Unraid server: robocopy /E /R:5 "D:" "\\NEBULA\Backups\FiLaptop\04-01-2023" /XF ._Thumbs.db /XD "D:\$RECYCLE.BIN" This completed successfully, but I cannot see this folder in either Windows explorer (from the same laptop that the robocopy command was run), or Mac finder: The files definitely exist on the server though: What could be causing this, is it a permissions thing? Edited to add - the reason for running this robocopy command is because the D drive on the Windows laptop out of the blue has become unable to create folders on it. The existing files are all still visible and you can open them, but you just can't edit or create anything new. Windows Error checking on that drive states "Repair this drive" so there is clearly something amiss which I am yet to investigate. First priority was just to get the files backed up in case the drives dies. I wonder if this is related somehow to not being able to see the folders in finder or windows explorer.

It passed the extended SMART test (attached) Samsung_SSD_870_EVO_500GB_S5Y1NF1R403281P-20221230-1044.txt