Local network blocks apps despite given permission on macOS Sequoia

Hi again,

just for clarity, there are no third party blockers/cleaners/testers on these machines -- they're pretty much plain vanilla, with the exception of VLC & Firefox (with eyeTV on a couple of them).

The key point in my last message was:

"The problem is the OS does not persist the local network authorization grant over a power cycle."

I'd suggest that, if you shut down the client machine, and then power it up (with or without Safe Boot), you'll hit the same problem. Firefox reports "can't access <remote web server on local network>". If you then goto the Local Network grant list, toggle Firefox off & then toggle it on again, THEN try the same access on the local network, it works.

I'd contend that this is a bug in Sequoia -- it's certainly a feature introduced by Sequoia that doesn't persist over power cycles.

It confused my users enough I've rolled all the machines back to Sonoma -- my bad for not testing this out, as 'obviously they wouldn't break something that simple'. Sigh. 2024, eh?

Seroiusly? Third party browsers that access devices on the local network DO most certainly need this authorization grant.

This problem -only- affects third party apps; Apple built-in apps & services are blessed and don't have this problem in the first place. From this, it seems you define "Most people" to mean folk who don't access devices on the local network, or ONLY use apple built-in apps. For everyone else...

The problem is the OS does not persist the local network authorization grant over a power cycle.

It is the same with different machines all now running Sequoia, with different user accounts, whether upgraded or installed from scratch & migrated, or just test accounts. I've tried several machines here and occupied way too much of my time.

Install Sequoia 15.2; try to use Firefox to connect to a local device (that's running a web service, obviously). First time you try it, it pops up an "allow/don't allow" dialogue box (and blocks the request). Clicking "allow" adds the app to the local network grant list. Try again to access that device & it works. Confuses the end users, but Fine.

Now power cycle the machine, and try again to access the device using Firefox -- it doesn't work. As the OP says, switch off the access right in system settings and then switch it on again, and everything works as it should.

Thanks to the OP, we have a solution -- it's kludgy, but it DOES work consistently.

The solution I've chosen is to downgrade all my machines back to Sonoma -- that works as well.

First, if you have some problem, and you migrate everything from one mac to another, the problem usually comes along.

Second, access to "local network" is not necessary for most any applications. It certainly is not needed for browsers. Most people have an empty list of applications there.

Create a new user, and test. Does it show the same problem? If it does, then this is probably due to some party modification (system extension, agent, daemon). If not, then it is something specific within your usual account.

Please do tell us which is the case.

In order for us to try and figure out what is causing you trouble, we need to know more. Please run Etrecheck and post its full report here. Use the "additional text" button and paste the report into the text box.

Hi again folks,

OK, several mentions of mDNS (Multicast Domain Name Service) & Bonjour & UPnP (Universal Plug and Play). TL;DR: this problem isn't that[*].

----

Bonjour is based on multicast announcements on the local network. It's multicast, so interfering with it so it affected other machines would require jamming the network. That isn't going to happen. As an aside, mDNS (or microsoft's alternative LLMNR (Link Local Multicast Name Resolution) isn't UPnP. That last is used by machines/devices to talk to the router, not to other machines on the local network.

----

From my experience, while firing up a disc running Sequoia and creating yet another test account, this problem came back as a "hard fail" on that Mac.

Running Firefox & VLC & Discovery (from the app store) for the first time required allowing a local network authorisation grant for each before these could connect to services on the local network.

Reboot (or Shutdown/power on) caused the machine to block Firefox (and VLC) from accessing those services. Curiously, Discovery still was able to scan for Bonjour multicast service announcements.[*].

Opening up the local network grant table and switching *any* app setting made Firefox & VLC work again. Thus, I switched Discovery to "off", and voila: Both Firefox & VLC sprung to life.

Not wanting to go all Cory Doctorow on this new feature, it's badly flaky if changing *any* grant in the UI affects other app grants.

Speaking of UIs, can anyone work out why some security & privacy app lists have a +- bar at the bottom (e.g. Full Disk Access), but others (like this Local Network grant list) don't? There's no way to remove an app from this list. Sigh.

Whatever -- I'm with the OP on this one:

• it IS a Sequoia bug, affecting any machine that is running Sequoia and using third party apps that access local network services. More importantly, the more I test this the flakier it seems. I can't let this loose on my users.
• Of course, as apple apps & services are blessed, I'd expect AFP/SMB/file access to continue to work fine. I'd expect file sharing to a NAS to work for a Sequoia client as it'll be using the Apple file sharing client code; accessing a web server on the NAS, not so much if you're using a third party app.

all the best, Lawrence

*: Running Lily Ballard's excellent app 'Discovery' on Sequoia confirms that Apple's Bonjour client code still works fine -- service discovery is working on Sequoia. Also, it's interesting that Discovery still works after a power cycle or reboot. It requests an access grant the first time it runs, but still works post reboot/power cycle when all other third party apps are blocked from local network access.

I wonder if that's because Discovery is using multicast rather than unicast networking -- it'd be hilarious if the devs had forgotten to block Multicast too in this new security feature.

You are right that third party applications need permission to access local network.

This was new to me. I can confirm that it that way, at least in Sonoma and Sequoia.

I have now had the chance to try it on my home network.

I turned on the built-in web servers on two macs: an M4 Pro MBP running Sequoia 15.2 and an Intel MBP running Sequoia 15.1.1.

I tried to access both the localhost (i.e. the server on each machine itself) and the other mac, using their LAN IP addresses.

Accessing localhost worked immediately.

Accessing the other mac, in both cases:

Firefox said it needed permission, which I granted. It was not enough to grant permission and reload the page, but after quitting and restarting Firefox it then could see the web page served from the other mac.

So at least here http access to a local resource appears to work and honor the permissions set.

I have to stand by my assumption that for those where it does not work there is probably something else locally (antivirus? cleaner? vpn? something other like little snitch? I don't know)

For those affected, I'd try in Safe Mode for comparison.

What apps are you talking about?

Where and how did you give them permission, and to do what, exactly?

It looks like you are using some third party firewall or other program like Little Snitch.

Try turning those off.

Hi there,

Thanks for confirming you don't have a problem with an apple silicon machine. All of the affected machines here are Intel (a set of 2020 iMacs & 2018 Mac Mini).

I hate problems like this: Re-installing a clone of Sequoia on a spare iMac, the "hard fault" (happens every time) has switched to a "can't reproduce" (never happens).

All I have done is reinstalled from a clone that displayed the problem BUT ... I did switch the local network grant toggle for Firefox off & on again; Its the only thing I did on this system since it displayed the "can't access..." in Firefox, prior to making the clone I've just re-installed.

So ... I wonder if it doesn't persist after the first power cycle, but toggling the local network grant off & on makes it "remember" from then onwards.

I won't have a machine available to go through the whole [clone a sonoma system; upgrade; run a Firefox local network client request, enable the local netwoork grant; power cycle; test the Firefox local access again (without toggling the local network grant for firefox)] procedure until the weekend, but toggling the network grant off & on does seem to make it "stick" -- it's the only thing I've done.

Ah well ... Merry Christmas, one and all.

Does this problem only exist for the NAS and the NAS-connected NVR? Which brand of NAS is it?

You say that you don't have a firewall activated - does that include a built-in firewall on the NAS (or the network access settings if it doesn't have a full-feature firewall installed)?

What I'm getting at is - if this problem only happens when connecting to your NAS, the NAS might have the issue. I had to reinitialize a QNAP recently and had an issue with mDNS that required a local subnet pass rule to fix properly, even though it was supposedly uPNP compatible.

Drag the app to your desktop and then back into the Application folder.

Thank you for the clarification.

I have now just restarted my mac (M4Pro MBP, running Sequoia 15.2).

I cannot reproduce the problem. All the applications allowed "Local Network" access kept their permission after restart. I tried to access to web server on the other mac and Firefox had no problem.

Maybe I'm just lucky, or maybe there is some peculiarity causing this in your system that we have not yet been able to determine.