tillkrueger

nope, it doesn't make any sense to me...I'll be throwing in the towel for the time being. all things being equal, my rMBP is logging in fine and connecting to my unRAID system, and my iMac is not...both connect via WiFi DHCP, both have ethernet unplugged (and why should I have to unplug ethernet anyway?!), but only one machine works as designed. wasted too many hours hours since yesterday and must get some real work done...so frustrating!

I have not tried that yet, Jcloud, but shall do so right now. I have isolated the problem, though, to the fact that when I use *only* WiFi, I can successfully connect through the VPN, but when plugging in ethernet again, it stops working...there seems to be something going on with the IP assignments between ethernet and WiFi...totally erratic behavior, where I could get it work, briefly, 15 minutes ago, then it stopped working again. I'll try that test and report back, thanks.

just found some info about this particular error, having to do with routing tables that are set up...gonna inquire deeper and report back.

While everything works exactly as designed now, there is one very annoying problem I still have. My IT guy in Berlin set up a VPN profile for me, so that I can securely log into my VLAN to administer my unRAID without leaving tons of ports open on the exposed public IP that he assigned to it (which has only ports 80 and 443 exposed)...the issue is that when I connect to this VPN profile from my iMac, the VPN assigned IP is not accessible...when I do the same from my rMBP, all works as designed. When I try to ping that IP from my iMac, I get this: till$ ping 10.0.195.2 PING 10.0.195.2 (10.0.195.2): 56 data bytes ping: sendto: Cannot allocate memory What could cause a "Cannot allocate memory" error? I have connected through this VPN profile successfully, in the past, but now it's not working anymore when everything else network-related is working perfectly well.

Wow, who'd h'thunk it? the 10.14.1 upgrade raked havoc on my system again...after the update, network behaviour was totally messed up again...not sure what is up with that, but my hardware (it's an iMac 27 late 2012) does not like Apple's latest software. I'll be interested to see what comes up on Google over the course of the next while. I'll be staying with 10.14 for a while then. Restoring, yet again, as I type this.

that's a good theory, jonathanm, but I had already restored to the previous backup overnight and am booted into it now, without any such issues...also, I did have those same issues even when using manually assigned (and unique) IP numbers...I have a system for assigning IP numbers that I use for all of my machines and devices, so that double IP issues won't happen. I will do the upgrade to 10.14.1 again and see whether it will still be ok after that...will report back.

Although I did just find this article, which proves that Apple isn't beyond breaking a network port through an update...it was back in 2016, and it's unlikely that this is the issue, but it does happen, apparently...time will tell.

good tip...but a first search came up empty...it's early, though, so I'll check back in the morning...by then the current backup will be done and I can try rolling back to the last one for confirmation, bc I know everything was working fine 8 days ago. If it doesn't anymore, then my iMac's hardware has gone faulty...here's to hoping that it didn't. enough head scratching for the day...g'nite to ya, lad!

I never touch the MacOS Firewall (always OFF), and there is no firewall in any of the routers here that wouldn't also affect the other machines, which all work fine. So yeah, a hardware issue in the iMac would explain it, but I somehow doubt it. (just a feeling) I had just upgraded to 10.14.1 prior, so I am thinking that a software issue is more likely...but I also doubt that that particular upgrade did it, knowing Apple's usually pretty stringent beta cycles. My last backup is 8 days old but I have added about 100GB of data to the boot-drive since (not entirely sure what added that much), so I am somewhat reluctant to take that big a step back, but I may have to in order to find out whether this really is a hardware issue or not. I'll make a backup of what I have first, then do a restore to the last backup after that to see where that leaves me.

I have just lost 4hrs of my life and a lot of hair over the weirdest thing...my iMac (and only my iMac) is losing contact to the internet seconds after I plug in the ethernet cable...it will briefly connect and start refreshing web-pages, then fall back into some mysterious mode where all web-services will fail to connect...Dropbox, the Adobe CC client, AnyDesk, web browsers, etc. will all go blank...my network settings for ethernet (and WiFi) are set to DHCP (I also tried to set them manually, same thing), and do fetch an IP and DNS, but within a few seconds of unplugging and re-plugging ethernet, they will all go blank again...for about 3-5 second I can load pages fine, but then something goes awry. I have rebooted the router multiple times, and have done the same with my iMac. My MacBook Pro, which sits right next to my iMac works just fine...iPad Pro and iPhone, both connected via WiFi, also work as expected. But something with my iMac is going awry and I am at the end of my wits after wasting the entire afternoon trying to get it to behave. Curious, also, is that when I unplug ethernet and enable WiFi, then the WiFi connection will work for a few seconds before it, too, will fail to stay connected to the internet. So I think I can rule out a faulty ethernet cable (purchased new last week). What could be causing such behaviour?

I thought I had deleted this thread right after creating it, because: Duh! My bad! I hadn't yet started the array after changing the port numbers to the WebGUI! well, now that it's up, I guess I'll leave it up in case someone else makes the same silly mistake Thanks for that tip, though!

Yes, I know that exposing unRAID to the internet is not recommended, but if the necessity arises, what factors in what order need to be considered when doing so? I'm starting to study the threads about setting up unRAID with a reverse proxy, letsencrypt, etc., but wanna do the most critical things first to lock down the system as best as is possible with ports 80 and 443 exposed.

I just went through a bunch of upgrades to the way my unRAID system is set up, starting with upgrading to dual-parity and a change of how it is accessed from outside (a combination of direct access via an IP number in a VLAN and VPN access). Because portions of it will now be directly accessible via an IP number and exposed to the outside world, I also increased the security of the root password and moved the WebGUI to another port so that port 80 can host a Docker like letsencrypt. All is back up and running now, but all the Dockers that I had configured (Krusader, QDir, ZeroTier) and VM's (Windows 10 and Windows Server 2016) have disappeared from my Dashboard. Why is that, and what's the best way of getting them back, hopefully without having to re-install and re-configure all of them?

You’re right, I forgot to try that before starting the parity rebuild...will try that over the weekend.

ah, ok, thanks for letting me know...too bad...seems like an important function to control independent of the WebGUI to recover from situations such as the one I find myself in...when the WebGUI starts acting up like this...still gonna have to try to figure out what is going wrong with the GUI when I'm done with this process...or maybe even during.

huh, that's pretty sweet during times like I am about to go through...I wasn't even thinking about that before I upgraded to dual-parity. thanks for confirming, jonthanm!

btw, if having dual-parity means that unRAID can recover from dual disk failures, does that then mean that one could upgrade two drives at once, to larger drives? (accepting the greater risk, as there would be trouble if a third disk failed during the upgrade of the two drives)

Hope you've had a good time out there! I also thought there would be no danger, but with the WebGUI being so wonky that that pretty much *every* operation doesn't work the first (or second or third or fourth...) time around, I never know what instruction just got executed on the backend...was it the New Config that just refreshed the page, or was it the disk I just re-assigned? Long story short, when I just spent almost an hour on the phone with my IT guy there who physically swapped disks for me, Slot 11 suddenly stopped working altogether (would see any disk that was inserted into it), and when I assigned disks that were moved from slot 04 and 05 to slots 12 and 13, those slots suddenly showed as blue, when all other assigned slots showed as green, making me worry that had I started the array in that state, it might have thought that those were new disks and start formatting/clearing them. long story short: the WebGUI has become totally unreliable and mostly unresponsive...I never know whether a command I issued via it was actually executed...so that's no viable way of working with unRAID. How can such a wonky WebGUI be trouble-shooted? And just to ask the same question for the 4th or 5th time: what would be the terminal methods for doing a clean stop array, and a New Config...if I could do those via terminal for now, then I could at least make progress on the new disk-configuration and upgrades while trying to figure out the WebGUI issues with the help of the esteemed unRAID community. If I don't talk to you today anymore, have a good night jb. you are one of the true blessings of this community.

when I refreshed the Main page just now, all slots showed as empty...can I assume that unRAID actually did execute the New Config, and proceed with assigning dual parity and all other slots as they were, then start the array again to re-calculate parity, *without* the danger of something terrible happening when I do that? there is no other reason why all slots would show as empty, other than the New Config having worked in the background, right?

ok, not sure why, but the GUI finally accepted the STOP ARRAY request...it won't take my New Config request, though...can I do it (and stop the array) via Terminal? (sorry for sounding like a broken record)

and again, after this reboot, I cannot stop the array via the WebGUI...is there a terminal command or command sequence for that? what is wrong with the WebGUI???!!!

thanks reboot appears to be initiated...let's see what the system comes back with, and whether I can then initiate a clean reboot in safe mode. how do I select safe mode? is that the same as selecting the array not to mount after reboot, or is there more involved? as I showed in the post above, I do not see the Advanced toggle when I look at the Flash disk tab...am I looking in the wrong place? and is there a sequence of commands or a command to do a New Config from Terminal?

but I need to ask again: what is the sequence of commands to do a clean stop array, reboot, and New Config? then, at least, I could get around the wonky WebGUI until I make some progress with the array upgrades/changes...my IT guy there wants to go home for the weekend.

ugh...*nothing* about the WebGUI is working as it should right now...what the heck is going on?! I don't see the Advanced view, if I'm in the right place.

and again, 15mins (why?!) later that empty Log window populated with the following: ErrorWarningSystemArrayLogin Oct 19 19:23:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:24:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:25:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:26:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:27:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:28:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:29:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:30:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:30:36 unRAID kernel: scsi 5:0:11:0: Direct-Access ATA WDC WD8003FFBX-6 0A83 PQ: 0 ANSI: 6 Oct 19 19:30:36 unRAID kernel: scsi 5:0:11:0: SATA: handle(0x001c), sas_addr(0x443322110e000000), phy(14), device_name(0x0000000000000000) Oct 19 19:30:36 unRAID kernel: scsi 5:0:11:0: enclosure logical id (0x500605b002c8b369), slot(13) Oct 19 19:30:36 unRAID kernel: scsi 5:0:11:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: Attached scsi generic sg12 type 0 Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: Power-on or device reset occurred Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: [sdm] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB) Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: [sdm] 4096-byte physical blocks Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: [sdm] Write Protect is off Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: [sdm] Mode Sense: 7f 00 10 08 Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: [sdm] Write cache: enabled, read cache: enabled, supports DPO and FUA Oct 19 19:30:36 unRAID kernel: sd 5:0:11:0: [sdm] Attached SCSI disk Oct 19 19:30:38 unRAID kernel: scsi 5:0:12:0: Direct-Access ATA WDC WD8003FFBX-6 0A83 PQ: 0 ANSI: 6 Oct 19 19:30:38 unRAID kernel: scsi 5:0:12:0: SATA: handle(0x001d), sas_addr(0x443322110b000000), phy(11), device_name(0x0000000000000000) Oct 19 19:30:38 unRAID kernel: scsi 5:0:12:0: enclosure logical id (0x500605b002c8b369), slot(8) Oct 19 19:30:38 unRAID kernel: scsi 5:0:12:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: Power-on or device reset occurred Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: Attached scsi generic sg13 type 0 Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: [sdn] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB) Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: [sdn] 4096-byte physical blocks Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: [sdn] Write Protect is off Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: [sdn] Mode Sense: 7f 00 10 08 Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: [sdn] Write cache: enabled, read cache: enabled, supports DPO and FUA Oct 19 19:30:38 unRAID kernel: sd 5:0:12:0: [sdn] Attached SCSI disk Oct 19 19:31:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:32:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:33:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:34:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:35:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:36:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:37:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:38:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:39:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:40:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:41:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:42:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null Oct 19 19:43:01 unRAID crond[1535]: exit status 127 from user root /usr/lib/sa/sa1 1 1 &> /dev/null