In case anyone else finds themselves here for a similar reason to me, I just thought I would chime in that the problem I was trying to solve was network issues with webhook calls for local network devices from an old version of node and node-red. Updating the nvm/node/node-red stack to the latest versions magically fixed the issue without me needing to add `node` to the `Local Network` pane in system settings. No more host unreachable errors (EHOSTUNREACH).
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Local Network Access Nightmare
- Thread starter MOM20xx
- Start date
- Sort by reaction score
From my notes, just went through it:
Force-delete persistent Network Extension configuration after app removal in MacOS Recovery Mode.
It is required when deleted applications leave orphaned services that block Local Network permissions (e.g. crashed VPNs, security tools). The configuration can't be deleted while the OS is running. Most of the configuration files are protected by System Integrity Protection (SIP) during normal boot. Recovery Mode bypasses SIP.
Example of orphaned service: synergy-service
Location: System Settings > Privacy & Security > Local Network
Config file disk location: Macintosh HD/Library/Preferences/com.apple.networkextension.plist
IMPORTANT NOTE: Backup first as this will reset all network extensions and more
-------------------------------------------------------------------------------------------
1. Shut down the computer: Apple menu > Shut Down
2. Boot to Recovery:
a. Press the Power button and hold it until 'Loading Startup Options...' text appears
b. Select: Options > Continue > Authenticate as admin
c. Open Terminal: Top menu bar > Utilities > Terminal
3. Identify system volume (ignore external drives): diskutil list internal
4. Unlock FileVault (if enabled): diskutil apfs unlockVolume disk3s4 -passphrase "your_mac_login_password"
* disk3s4 for disk3 and partition 4, replace it by your 'Macintosh HD - Data' identifier
* omit -passphrase to enter password interactively
5. Mount & remount system volume (-u for update existing mount and -w for enable read-write mode):
a. diskutil mount disk3s4
b. mount -uw /Volumes/Macintosh\ HD
6. Access the file system: cd /Volumes/Macintosh\ HD/
7. Delete the com.apple.networkextension.plist configuration file (-f for force)
a. cd /Volumes/Macintosh\ HD/Library/Preferences
b. rm -f com.apple.networkextension.plist
c. Confirm deletion: ls -la | grep networkextension
8. Reboot: Apple menu > Restart
Important Post-Recovery Actions:
a. System Settings > Privacy & Security > Local Network
Apps might not work until re-added: Open the app and it should trigger permission prompt
b. System Settings > Network > Firewall
Firewall will be turned off, reset to defaults and all custom rules lost: Turn on and re-configure the Firewall
c. System Settings > Network > Filters & Proxies
Re-enter the app manually or open the app and it will trigger permission prompt
d. System Settings > General > Login items & Extensions > Extensions (select 'By Category', Tahoe only) > Network Extensions
Network extensions (e.g. ad blockers) will be disabled until re-enabled
Pro Tips:
a. If rm fails, the file may be locked by a kernel extension. Boot into Safe Mode first (shift key at startup)
b. Always uninstall apps via their official uninstaller before deleting app bundles
c. Last resort only: If the file reappears after reboot, the orphaned service is still registered.
Run in terminal before deletion: sudo launchctl remove com.apple.networkextension
This procedure is irreversible and may cause system failure or instability.
It seems I spoke too soon. I have 2 computers that I did this on, both mac minis. One is still solved - no `EHOSTUNREACH` errors. The other (which uses the http request nodes less frequently) is again giving me the errors. I'm currently trying to fix it...
Ran into this today - app never requests access (but needs it) and can't add it manually. That last part is the root issue here - Apple needs to give us a way to manually add apps to the list like we can for disk access.
BobbyCat
macrumors regular
I'm very interested in your method if it solves the problem, but your link doesn't work, it just says "Corrupted Content Error"
Would be nice if you tried again, thanks.
brice_
macrumors newbie
I tried to locate the `com.apple.networkextension.plist`, `com.apple.networkextension.uuidcache.plist`, but I couldn;t find them in recovery. `disk3s4` appear to be already mounted under `/System/Volumes/Update`, but the files seems purely technical, i.e. no `System/`, or `Library/` under it. Tried to remount this partition without success.
In the end doing the `csrutil` based approach was faster and `no brainer`, even accounting two reboot in recovery.
In the end doing the `csrutil` based approach was faster and `no brainer`, even accounting two reboot in recovery.
haralds
macrumors 68040
Update: I did have to go in and turn off SIP, then delete the plist, then turn SIP back on.
I think (!) I have a solution to this problem once and for all (a bold claim, I know!)...
I am using a recently acquired 2018 Mac Mini (running Sequoia) as a little home server and I need to start up several services from the command line. These were completely broken by this frankly brain-dead Apple "feature"
I tried deleting the .plist file as suggested previously and it did indeed work. And then a couple of days later, the problem came back. I looked about and found that the .plist file had re-appeared (though it was not the same as the previous one that I had saved away ...just in case). I was about to give-up and send the Mac to landfill...
...and then I stumbled on this...
developer.apple.com
In summary (for when the above falls off the wobbly web), this describes the brain-dead feature in question and goes into detail about how it is designed to ruin your life. Something I found very interesting was a statement saying that command-line applications are not effected by this feature - I can categorically state that this is total b******s; they are very-much effected
But, even more interesting, it suggests a way of switching this lovely feature off (about half way down the page under the "MacOS Considerations" section). Access to the local network via Ethernet is controlled separately to access via WiFi, which is uncharacteristically helpful. The magic runes you need are as follows (you can just run these from a normal boot - no messing about with recovery mode)....
Ethernet....
WiFi...
(obviously, you adjust the netmask according to your local network)
You then need to reboot for the change(s) to take effect
I am not familiar with the '-array' syntax, but it suggests you can maybe add multiple networks - possibly useful for a laptop moving between different WiFi environments? Alternatively, maybe you could just set the netmask to "0.0.0.0/0" and it would remove all restrictions? (I have not tried either of these ideas though - I would be interested if anyone tries them)
Anyway, I can confirm that (so far) this is working for me (at least until Apple put out an update to f*** it all up again)
I am using a recently acquired 2018 Mac Mini (running Sequoia) as a little home server and I need to start up several services from the command line. These were completely broken by this frankly brain-dead Apple "feature"
I tried deleting the .plist file as suggested previously and it did indeed work. And then a couple of days later, the problem came back. I looked about and found that the .plist file had re-appeared (though it was not the same as the previous one that I had saved away ...just in case). I was about to give-up and send the Mac to landfill...
...and then I stumbled on this...
TN3179: Understanding local network privacy | Apple Developer Documentation
Learn how local network privacy affects your software.
In summary (for when the above falls off the wobbly web), this describes the brain-dead feature in question and goes into detail about how it is designed to ruin your life. Something I found very interesting was a statement saying that command-line applications are not effected by this feature - I can categorically state that this is total b******s; they are very-much effected
But, even more interesting, it suggests a way of switching this lovely feature off (about half way down the page under the "MacOS Considerations" section). Access to the local network via Ethernet is controlled separately to access via WiFi, which is uncharacteristically helpful. The magic runes you need are as follows (you can just run these from a normal boot - no messing about with recovery mode)....
Ethernet....
sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "169.254.0.0/16"WiFi...
sudo defaults write com.apple.network.local-network AllowedWiFiLocalNetworkAddresses -array "169.254.0.0/16"(obviously, you adjust the netmask according to your local network)
You then need to reboot for the change(s) to take effect
I am not familiar with the '-array' syntax, but it suggests you can maybe add multiple networks - possibly useful for a laptop moving between different WiFi environments? Alternatively, maybe you could just set the netmask to "0.0.0.0/0" and it would remove all restrictions? (I have not tried either of these ideas though - I would be interested if anyone tries them)
Anyway, I can confirm that (so far) this is working for me (at least until Apple put out an update to f*** it all up again)
Last edited:
bogdanw
macrumors G3
Great find!
In Tahoe 26.5, I run
sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "192.168.0.0/16", rebooted, then installed Chrome and accessed the router at 192.168.0.1. It didn't ask for permission to access the local network and connected just fine.