superloopy1

Thanks for your efforts there, all understood. My speeds are all over the place again following the reboot and no downloads can be initiated. It's most strange. No activity was taking place at the time, the queue had emptied once speed WAS returned and the system was idle but its back to square one again i'm afraid. I'll make those changes and had intended to rebond/bridge everything everywhere, cant hurt can it?

Thanks all. I'm using port 563. Things have moved on a bit though and on next startup of SABNZBVPN i included the addition of a second 'spare' block server as a test and it completed albeit a lot slower than the usual 100-110MB download speed but suffice to say everything is relative and it did work, no slowdowns at all. So, posted this up earlier but it hasn't yet been 'modded' and not showing on the forum. So, the next reboot of the system itself and hey presto, my speed is back at 110MB downloads all round. I am guessing that the problem was with Ninja end .... or so i thought. I have ran against the server and all appeared well until i received a message from sab debug that access to /data on the cache wasn't aok and that /data/usenet complete and incomplete were both not available?? Cache checked for error and found to be ok but ... Soon to be followed by the explanation that 'no exportable shares' were available and true enough i had no share data showing anywhere? it is at this point that you begin to suspect that your data has possibly gone south but fortunately that doesn't appear to be the case and i'm at the point where i am about to reboot the system having taken both diagnostics and a flash backup. FYI global share settings appear to be in order (i checked) so i've no idea what is going on or whether the system is coming back after this reboot so here goes .... further updates later. tower-diagnostics-20261107-1642.zip

Guys, my sabnzb is screwd. Switched machine off for 3 weeks, previous 100MB speedy dowmloads and now wont even complete a sab test download, just peaks at around 200b/sec and drops like a stone ro zero. Everything works connection wise, sonarr, radarr, indexers etc, queue is being populated but just timeouts everywhere. I have switched google, cloudflare dns entries around but still nothing so i now want to see if provider dns do the same. But, stopping docker and trying to switch from static to automatic remains greyed out?? Any ideas ... i just connect one provider and all pings everywhere seem fine. I need to try automatic dns but cant and have a feeling my network config file is dodgy and needs fixing but how?? Couple of issues, bit of chicken n egg going on. Meanwhile no sab ...

did this ever get answered and is it a possibility at all?

I'm expanding the system by adding a larger drive to replace a smaller one having ran a parity check to ensure all data is ok. If the expansion process fails and the disk is being emulated how do i proceed. The original data disk is at this stage outside of the array but fully functional.

So, how do i get the original 14TB drives data back onto the array without losing it? Is it a case of mounting it externally and purchasing another drive for the array which then takes a move of the data, if so that seems a very long winded fix?

Thanks. so, data is intact on smaller, outgoing disk as to be expected. but if you just wanted to put it, and the contents, back into the system then how do you get the data back in sync? wont reinserting the disk just prompt to overwrite?

.... during a drive expansion ( i've removed a 14TB drive and am replacing with an 18TB) there is a problem? I still have the original 14TB drive. Is it simply a matter of switching it back in and restarting? Should the drive expansion be running in maintenance mode to avoid any detrimental activity should the expansion go belly up? Jsut sitting here watching it slowly restore over some 2.5 days!!

That 'other' parity was done in maintenance mode, thanks. Update ... just to say that I did do exactly that AND it logged 23 errors from switching over parity disks i suppose. Still running the 'old'parity recheck as i write so absolutely nothing gained and fours days of electricity wasted ! That did the trick, i'll not forget it, ta v.much!

I always knew there'd be a fix, thanks! So, new config, maintain all slots then the tick box. I'll let you know ...

Yet again, issues with parity. I've reached a point where advice is needed. Scenario .... upgrading my single 16TB parity drive to a larger 18TB drive. Simple eh. So, I ran a full parity check, all clear, on the existing drive. Unplugged old parity from existing cables and inserted larger drive. All went well, allocated new drive as parity and restarted in maintenance mode safe in the knowledge that my old 16TB drive could serve me well in case of problems. Parity sync running for hours then lost connection at around the 15hours to go stage. Nothing. Hooked up monitor, all dead. Fearing the worst I powered off and on and everything back as it was so away I went again. Same routine, maintenance mode and same thing happened although a little later in the sync process. So, I gave up and put it all back together with the old 16TB parity thinking I could ust switch and go. BUT ... I can reallocate the drive to parity but can't see any way to avoid having to resync and therefore losing parity on the old disk. That's not how I thought it worked. Can't see anywhere to say 'trust existing parity'. Am I missing something? What's the way forward without wiping out my trusted parity drive? Any advice would be appreciated. Thanks!

, sorry that read wrongly. how can dual parity be better at protecting the array when parity check running in maintenance mode moreorless is the question.

what changes to make it 'less iikely' to drop a disk though when using dual parity?

thanks for replying. is this 'parity rebuild in maintenance mode' documented anywhere?

Nobody had to do this then?