Local network access disabled after macOS restart

My application needs local network access.

By “application”, do you mean something that’s packaged as a .app that the user launches in the Finder? Or are you using that term in a more generic sense?

If this is an app, does it ship on the Mac App Store? Or do you distribute your product independently?

Finally, have you tried replicating this in a VM? These privileges are commonly mixed up on development machines. If you encounter something weird, it’s good to verify it on a VM that’s never seen your app before.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for your prompt reply.

My application is packaged as a .app package. It is distributed independently, not on the App Store.

I have tried two other apps (.app packages) that do similar things to my app. One is distributed via the App Store and works immediately after a macOS restart. The other is distributed independently and has the same issue as my app after a macOS restart.

I am testing by deleting my test volume, then creating a new empty test volume and installing Sequoia from scratch in that volume. This is simpler for me than creating a VM. Following a hint in TN3179, I have also tried creating a new user account to get a "clean sheet" of local network privacy settings and I see exactly the same issue when starting my app from this new user account.

I have tried running the Console app to see what is going on when the working app starts and when the failing app starts. The output from Console shows that the working app is populating a local network privacy cache when it starts, with messages like the following:

default 11:14:35.343586+0000    nesessionmanager    NESMPathControllerSession[com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7:A0036093-7F67-4D6A-AB13-F90153F11724]: No UUIDs in the cache for PathRuleDefaultNonSystemIdentifier, populating the cache from the path rules
default 11:14:35.343694+0000    nesessionmanager    Sending a message to populate the cache with UUIDs from configuration A0036093-7F67-4D6A-AB13-F90153F11724
default 11:14:35.345021+0000    nehelper    com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Populating the cache with UUIDs for 8 app rules
default 11:14:35.361911+0000    nehelper    com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Populating the cache with 1 UUID(s) for uk.co.linn.linn
default 11:14:35.361993+0000    nehelper    com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Saving the cache
default 11:14:35.473344+0000    nesessionmanager    UUID cache miss for com.minimserver.server
default 11:14:35.485558+0000    nehelper    Caching 2 UUID(s) for com.minimserver.server
default 11:14:35.487837+0000    nesessionmanager    UUID: Found for com.minimserver.server: (
    "D4B6F942-5D28-3D52-B279-C5766B3B0F70",
    "6CA3C8E4-0DBD-3B47-BD57-70CE30DB0547"
)

The app uk.co.linn.linn is the app that works immediately after a macOS restart and the app com.minimserver.server is my app that does not work immediately after a macOS restart. After this cache population has happened, all apps in the Local Network section are working normally.

Thanks for all the extra info. I’d like to try replicating this here in my office and there’s one critical piece of extra info I need: In the tests you’re running, is your app triggering the local network request via network traffic or via DNS?

That is, is the first local network operation you perform a DNS operation, like a Bonjour browse? Or does it immediate generate traffic on the wire, via a TCP connection or a UDP datagram?

Oh, if it’s a UDP datagram, is that a unicast, broadcast, or multicast?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks very much for all your help with this.

My app is a UPnP server. It creates a multicast socket that joins multicast group 239.255.255.250, which sends an IGMPv2 Membership Report message to the multicast group address 239.255.255.250. This is the first message sent to the local network. After this, the app sends an SSDP NOTIFY message to the multicast group 239.255.255.250 and waits for UDP unicast responses from other UPnP devices. There are no DNS messages sent.

When local network access is disabled, the IGMPv2 Membership Report message is sent (confirmed by using Wireshark) but the NOTIFY message is blocked.

There is another variation on this (UPnP client mode) where an SSDP M-SEARCH message is sent after joining the multicast group instead of sending a NOTIFY message. Again, the IGMPv2 Membership Report message is sent but the M-SEARCH message is blocked.

There is another case where the app accesses a remote internet server before joining the multicast group as described in my previous post. In this other case, a DNS request is sent via the gateway router. I have tried both cases (no DNS request and gateway router DNS request) and the problem occurs in both these cases.

Is there any update on this issue? Should I create a bug report for it?

Sorry I didn’t respond earlier; your messages got lost in the Thanksgiving maelstrom.

I have one long shot I’d like to try before we go further: When you’re testing this on a ‘clean’ machine, is the app in the Applications folder? If not, please repeat your tests but place your app there.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

All my tests have been made by downloading the app (packaged as .app in a .dmg file) from my download website, dragging the app from the .dmg file to the Applications folder and then launching the app from the Applications folder using Finder.

Greetings,

We've been facing the same problem recently and want to share some of our observations in the hope, that they may be helpful. When I say the issue was fixed temporarily in these bullet points, I mean it works until the next restart - just like when one disables and reenables the permission.

• Logging out and logging back in after the reboot reliably fixes the issue.
• From the point of view of the app it looks exactly the same as if the permission was not given (NWConnection runs into a localNetworkDenied).
• Running another version of the app with a different bundle name sometimes created a second linked permission in the local network permissions and fixes the issue for multiple reboots. Eventually this fix broke down in some cases for unknown reasons.
• We once observed a newly created user on a problematic machine not having this issue. On that machine it was fixed with the method from the previous bullet point for another user. We couldn't replicate this behaviour on another problematic machine though - there the issue reappeared for the new user.
• The issue sometimes temporarily fixes itself after a few minutes. We opened VLC and TeamViewer connections shortly before it did every time, but that may be coincidence.
• One of our customers came up with this shell script (which they configured our software to automatically execute on start), which solved the issue for them (but probably causes to much collateral damage in general):

do shell script "networksetup -listallnetworkservices | tail -n +2 | sed 's/^*//' | while read thisName; do networksetup -setnetworkserviceenabled \"$thisName\" " & "off" & "; done" user name "****" password "****" with administrator privileges

do shell script "networksetup -listallnetworkservices | tail -n +2 | sed 's/^*//' | while read thisName; do networksetup -setnetworkserviceenabled \"$thisName\" " & "on" & "; done" user name "****" password "****" with administrator privileges

• We've tried moving the app around. Normally it is in a subdirectory of the user directory. Neither moving it to desktop nor to applications fixed the issue permanently - though sometimes executing it in another place fixed it temporarily. This was very unreliable and I wouldn't be surprised if it was just random. This wasn't done on a clean machine though.

Happy holidays.

You’re definitely not alone in seeing this problem. Clearly zollsoftTomedo is seeing it as well, and there’s also this thread.

All my tests have been made by downloading the app … from my download website, dragging the app from the .dmg file to the Applications folder and then launching the app from the Applications folder using Finder.

Can you share a link for that download? I’d love to try this myself.

If you have problems posting your link, see tip 14 in the Quinn’s Top Ten DevForums Tips.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The downloads page for my app is here:

https://minimserver.com/downloads.html

Under MinimServer downloads, select the "Intel and Apple Silicon" link in the macOS row. This shows a pop-up window. In this window, select "I accept these terms and conditions" and click the Download button.

Now install Java 21. There are instructions for downloading and installing Java on this page:

https://minimserver.com/install-java-macos.html

Open the downloaded .dmg file and drag the green MinimServer icon to the Applications folder. Launch the MinimServer app and confirm that you want to open an application downloaded from the internet.

If you see a pop-up saying that MinimServer wants access to control SystemUIServer, click Allow. If you see a pop-up saying that MinimServer notifications may include alerts, sounds and icon badges, click X to close the pop-up.

You should now see a pop-up asking if you want to allow MinimServer to find devices on local networks. Click Allow.

MinimServer should start successfully and show a transparent icon (musical minim note) in the menu bar. If you did not allow local network access, you should see an error pop-up. Closing this pop-up will cause the minim icon background colour to change to red.

To close the MinimServer app, click the minim icon and select Exit from the drop-down menu.

If local network access is enabled for MinimServer, you should be able to close and relaunch MinimServer any number of times with no errors.

Now reboot macOS and try to launch MinimServer. You should see the error message about no local network access even though MinimServer is showing as enabled in the Local Network section of Privacy & Security. Turning this permission off and on should enable MinimServer to start without an error message.

Sadly, I don’t have the bandwidth for dealing with Java today. However, Java is notoriously problematic for TCC, so this doesn’t come as a huge surprise.

My advice right now is that you file a bug about this. Please post your bug number, just for the record.

I’ve set a reminder to check on this when I’m back in the office next year.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"