whatabout

Thank you for that information. As this array has been without parity for some time now while I chased these errors, I opted for the downgrade to v6.12.4. Parity sync is now at 76.7% without encountering a single error.

Hello, For a few weeks I've been seeing errors scatter across all disks in my server. These errors occur across all backplanes, cables, ports. They've reappeared following new configs, component replacements, etc. If a new config is applied and no parity device declared, it seems that all disks will hum along without issue. However when a parity action is began, whether sync/rebuild/read, it is inevitable that before long a disk will encounter errors. And then another, and another, until the system pauses that parity action or I intervene to cancel it. Until today when I installed an all new CPU _and_ motherboard. Kicked off a parity sync, and, again, errors begin appearing on every disk. I've replaced: - Controller - RAM - Motherboard - CPU I've attached diagnostics captured immediately after cancelling that parity sync. box-diagnostics-20240209-2006.zip

Mine's stopped connecting to the swiss pia server, also without any known changes. The PIA desktop client connects to both, though. ¯\_(ツ)_/¯

Were you able to solve this, @ipreferpie? Similar issue for me here, just recently.

Thank you so much, binhex. It was due to a GeoIP restriction on the firewall blocking the country of this specific server. I added that country to the allow list and everything is once again operational. Not sure why it had worked previously, as I hadn't recently changed any of these settings. Perhaps the GeoIP feature only recently identified the server's location. ¯\_(ツ)_/¯

Very good point. Same symptom is not the same problem. I've attached supervisord here. Thank you for assistance. supervisord_2020-02-04_07-42.txt

I've got the same problem. Two separate binhex-delugevpn containers were working absolutely perfectly until this past Friday evening. Suddenly, neither were reachable via webUI and I began to incur hit-and-runs on the tracker. I've tried re-creating them from scratch, even using empty /config. I've also tried them on another host. I've used new openvpn files. I've even tried airvpn instead of pia. I can get vpn-less Deluge containers running no problem. But it seems no matter what I do I cannot get binhex-delugevpn to work. Same goes for binhex-qbittorrentvpn and binhex-rtorrentvpn. The containers start but then …nothing. And the logs don't have a smoking gun. Unfortunately renaming core.conf has no effect either way.

Newegg says the case is ineligible for a replacement RMA since it was purchased more than 30 days ago (been getting pieces for this build slowly, as I can afford them). So your second suggestion may be the way to go. A restocking fee (plus shipping the beast back to them, I'd imagine) will probably be cheaper than buying this many new backplanes. I think I recall them being in the $50-$55/apiece area. Yes, when I tested the backplanes each backplane was powered independently for its respective test. So while testing the first backplane, it was the only component - aside from motherboard and SATA controller - with any power to it and the only component connected to the SATA controller. And then, the second backplane was, and so on. Directly from the power supply, with no splitters. Also, a question has been raised in regards to the backplanes' dual power connectors, and whether I was connecting power to both or just one. The backplanes included with my case don't support PSU redundancy, having only one power connector per backplane.

From NORCO: I'll look into your suggestion re: RMA through the merchant. However, that merchant was Newegg and it seems that Newegg, Norco, Rosewill, et al are all under the same umbrella. I'd imagine I'll be paying for the replacement backplanes out-of-pocket.

Y'all are on to something here. Thanks for the mention of a forward-breakout cable. I discovered that I have one on-hand, and so was able to verify that the card does detect disks. Then I started on testing each backplane and its four slots. I found the same results with my Norco 8087-8087 cable as the Monoprice brand cable. Looks like I've got some bad backplanes. Most of them, actually. Only one has all four slots functioning. Row0: OOOO Row1: OOOX Row2: OXOX Row3: OOOX Row4: OOOX Row5: XOOO One of these non-working backplanes is a replacement of a physically (could tell by looking at it) -damaged piece, which also gave Xs across the row. Here's hoping they're up for sending five more replacements. Maybe they'll test them first this time? I have one other Norco-bound unRAID server (it's in a RPC-4220) and have had no issues whatsoever with any parts on that one. In the meantime, is it advisable to connect disks to the slots which _are_ working? unRAID handles disk placement not by physical connection but by disk identification, so I assume that rearranging them as I replace backplanes with fully-functioning units shouldn't be a problem.

That's good logic, Squid. Thanks for laying it down so I could follow it. Also I appreciate your assurance that this SuperMicro card does work. Motherboard: Biostar Hi-Fi A85W FM2 AMD 85X Power Supply: Corsair CX750M Case: Norco RPC-4224 Cabling: Norco C-SFF8087-D

Hello. I am encountering endless issues with selecting a compatible SATA controller. Motherboard installed is a Biostar Hi-Fi A85W FM2 AMD 85X and the onboard SATA ports work just fine. However each and every SATA card I've attempted has been returned in frustration. I've tried: - HighPoint RocketRAID 2680SGL - Syba SI-PEX40071 - SuperMicro AOC-SAS2LP-MV8 I should’ve taken better notes along the way, but here’re the basics of it. The HighPoint isn’t on the list at http://lime-technology.com/wiki/index.php?title=Hardware_Compatibility#PCI_SATA_Controllers and so when it seemingly did not recognize any installed disks, I chalked it up to complete incompatibility and moved along to the Syba, which is listed as “Works straight out of the box” on the aforelinked compatibility list. Well, it didn’t. Work straight out of the box, that is. As far’s I could tell it did nothing but add a new screen during the boot process. I’ve most recently attempted the SuperMicro card. On the compatibility list it says “should work out of the box but there were some issues” so I read through the linked thread (http://lime-technology.com/forum/index.php?topic=29052.0) where it was suggested to flash the card’s firmware. First I tried the card as it arrived, to see if it did just so happen to work out of the box. It didn’t. No sweat, as the firmware flashing procedure is very quick and straightforward. So I flashed the card with the new firmware following the procedure on that thread with which others had reported success. But no dice. I am still seeing the card’s screen during boot up, and it is still reporting “No Physical Disk!” I’ve attempted moving it to a different PCI slot, using a different SAS cable, different hard disks, different backplane in the case. Nothing seems to work. I’ve got a 24-bay server case, but cannot seem to utilize any more disks than the onboard SATA ports will address. Does anyone have any suggestion? I have 16 more drives to connect. PCIe is preferred, and SATA II or III are both acceptable. Or, better yet, any tips on how to get the SuperMicro card to recognize the physical disks attached to it!

Hmm. My first thought was, “No way! The download location is set right to the Downloads share, and disk18 is not included on that share.” But it got me questioning that assumption. And then I saw Riot’s link: and looked into that a bit more. As it turns out, the files _were_ being started on disk18. In SAB’s Folder settings, a leading / (slash) was missing in the “Temporary Download Folder” field. So the downloads were going into /mnt/user/AppData/sabnzbd-data/Downloads/downloading instead of /mnt/user/Downloads/downloading. Since correcting the missing slash, the share directories have not been created on disk18. I’ve only had one incoming file to observe this with, but from what I can tell that seemed to have fixed the issue. Is the array a proper location for incoming downloads, or should those all be going to the cache drive? After a few years of using unRAID and tweaking the way it (as well as the packages I run along with it) operates, I feel like things may be scattered more than they should. I wish there were a way to easily reorganize/redistribute existing data across the drives for best efficiency and capacity. But maybe that’s not as necessary as I think it is.

Thanks, all. That makes good sense. However I have moved the data off of disk18 and removed the directories, and they end up being created again. Gotcha, thank you. I'm now using the "Included Disk(s)" field only. Interesting. I haven’t encountered that before. Here, though, I’ve been moving the data off of the disk itself and the top-level folders for the shares are inevitably recreated. If SeasonNumber is on a disk which the TV share began using a long time ago - a disk which is nearly full - and the disk tops off before the end of the season, there’s nowhere for the season’s later episodes to go. When most disks are near capacity, I’ve come to be less particular about keeping entire seasons on a single disk. Perhaps I’m behaving insensibly? That certainly gets the data off of the disk. But the issue is why it is being placed there to start, and how to keep it from continuing. I’ve got some stuff on cache now, waiting for the mover.

Downloads is set to 4. (Example directory structure: DOWNLOADSSHARE>complete>movies>Files). TV is set to 4. (Example directory structure: TVSHARE>Continuing>ShowTitle>SeasonNumber>Files). I set these up to 4 because ongoing series were crowding out individual disks. Movies is set to 2. (Directory structure: MOVIESSHARE>MovieTitle>Files).