OK the thing that has cost us all this grief is that as of Sequoia the application needs to be running in /Applications - we've been testing it from the desktop folder/ other folders on the OS. For some reason if it's not running in /Applications you get this weird UDP error. Even if it's running as root. Moving it to /Applications has resolved all the issues. Apple, why do you do this?

We're having exactly the same issue running our application as a LaunchAgent as we did running it as a LaunchDaemon No route to host at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow) https://github.com/ispysoftware/agent-install-scripts/blob/main/v2/launchagent.plist It just doesn't work. We've done everything to try to get this working. We get the exact same errors in the console when running it as a launch agent that we did when running it as a launch daemon

I appreciate that you are an actual DTS engineer, and well done on that score, very impressive indeed. Unfortunately that doesn't have any bearing whatsoever on the fact that daemon servers used to be able to be run with user permissions and now cannot. The upshot of this is that it's categorically impossible to update our software to work fully on the latest version of macOS. We can either choose between a working server and no local device access or local device access and a broken server. A split up application using IPC calls isn't even an option because we'd need a user session to access the camera. This is a shame as i'm currently sitting in an office surrounded by completely useless hardware and have lost a month of development time and we're no closer to a resolution. Your goal of helping developers build software now and in the future has failed spectacularly in our admittedly rather specific case as this is the future from when it worked fine in the past. Fortunately macOS is a small part of our user base and we'll just have to tell people to use Linux or Windows instead and hope that at some point this is resolved.

So why doesn't the manual documentation say "This optional key specifies the role account to run the job as" then? You keep saying it's an unsupported configuration when it clearly isn't - at least, it hasn't been an unsupported configuration for years over numerous macOS iterations. If something has changed and it's now not supported then you need to update your documentation and manuals. The report here is that daemons running as an administrator user account (which has always been a supported configuration) cannot for some reason communicate over UDP. At least look into why that is please.

The manual documentation for UserName in launch daemon plist files says "This optional key specifies the user to run the job as." It doesn't say " intended to be used for role accounts, like the _www user. It’s not designed to move your daemon into a user session." If i ask chatgpt about it it says "In Apple's developer documentation, the UserName field in a launch daemon's property list (.plist) specifies the user account under which the daemon should run. By default, daemons run as the root user, but setting this key allows the daemon to operate with the permissions of a specified user." I'm really struggling to find where it says anywhere in the developer documentation that what we are doing is "not a supported configuration". From everything i can find on your own docs and forums, what we are doing is exactly how we are supposed to be doing it.

OK - i've spent a month trying to get this to work. There's really one outstanding issue and that's that some UDP packets are being blocked when our daemon is running under an admin user account. Can you confirm that that is by design? Are there any workarounds you can think of short of us completely restructuring our application? "You’re running as a daemon but pretending to be a user. The system is not set up for that because it’s not a supported configuration." So, i'm sorry but what is the point of the UserName field in the launchd plist file then? We could run this as root but then we lose the ability to access the camera and microphone which is not ideal for video surveillance. I just need to ascertain if this is a total dead end or if something is going to be done about it.

Thanks for responding. "Yowsers! Honestly, I’m surprised you’ve got this far." Well it was working fine on every version of macOS up to this one. It's also working fine as a service on Windows and every version of Linux - with local device access and networking. It's literally -=only=- Sequoia that there are problems on. I guess i'll just have to tell people to either use another OS, use Docker or just run it from the terminal. I don't understand why you make it so difficult to do things that on other OSes is simple. If someone gives an app root access then why can't it access local devices? It doesn't make any sense. And if an app is running as a service under an admin account (my account is an admin account) then why is it ONLY blocking these STUN responses? It's got network access and TCP works fine. That's the main issue here - the OS shouldn't be blocking this specific network traffic from our app - that's definitely a bug. Our app is cross platform i'm not splitting it into different apps with varying levels of privelege and using IPC just to work around a bug in sequoia. Our app is a video surveillance platform - it needs to start at system startup not login so running it as a launch agent isn't an option. It doesn't have a normal GUI it runs a web server. LaunchDaemon plist files have a UserName field for the specific purpose of running a system level daemon with specific user privileges. That's not something i've exploited it's part of your own system design.

Our service runs under a user account because it also accesses local devices like cameras and microphones. YOUR_USERNAME gets merged in by the installer. I found that if i install our app to Library/Application Support and run it as root then the networking issue goes away (but no local device access which makes this pointless). If it's installed like it was before on previous macOS iterations - on say the desktop and running with the user account then we get local device access but networking is borked. Also macOS won't prompt for permissions with root but will with the user account. I'm on latest macOS 15.2 beta. Also this help system isn't working properly - replies aren't displaying and the UI keeps telling me i'm at a negative word count and responses "must include text in the body"

Thanks @DTS Engineer I'm still seeing this issue on latest Mac OS 15.1 beta. Our app is a dotnet 9 executable called "Agent" that's code signed and has all the networking permissions added in entitlements and it's plist. It has a UUID. It works fine when run from the terminal under my (admin) account but will not connect when run as a launchd service using the same account. The server responds so it has network access but webrtc setup fails and STUN responses are blocked. Again - works fine from the terminal. In our app logs network device discovery code is being blocked: "Discover: No route to host at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow) at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.SendToAsync" the docs say that the mdns permission isn't needed to macos and in console i see default 16:34:32.099971+0800 nehelper UUID cache miss for Agent default 16:34:32.103499+0800 neagent Failed to find Agent in LaunchServices default 16:34:32.104192+0800 nehelper Failed to find Agent using neagent default 16:34:32.104723+0800 nehelper 0 UUIDs for Agent are already in the cache default 16:34:32.106107+0800 neagent Failed to find Agent in LaunchServices default 16:34:32.106211+0800 nehelper Failed to find Agent using neagent default 16:34:32.106319+0800 nehelper Removing UUIDs for ( Agent ) default 16:34:32.108937+0800 nehelper Setting UUID cache generation to 165 default 16:34:32.109041+0800 nehelper Local network allowed by preference for Agent (Agent), but received prompt. Clearing cached UUIDs and restarting session. This stuff should just work right?

Are there any updates on when this will be fixed?