macOS 15 connection issues

[soerenkampschroer]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the latest beta/pre-release?

This issue is present in the latest pre-release

Describe the Bug

On macOS 15 sunshine is not able to connect to the client when started as a service (brew services start sunshine-beta). The server will advertise but upon connecting the logs show that the connection times out.

It may be a permission issue connected to the new Local Network permission. As far as I know it's impossible to add or whitelist programs for the permission and there needs to be a popup where you can confirm or deny access. I did manage to get the last beta build to work as a service by deleting all sunshine related permissions and reinstalling it, but due to the frequent name change of the beta build it needs new permissions after every update. I have not been able to get the latest build running, even though I again removed all permissions and reinstalled the latest build again after doing the update.

However, sunshine works fine if it's started manually by running it in terminal as a command.

This was not an issue on macOS 14, so my guess is it's the new Local Network permission, which has caused issues with other apps as well.

Firewall is turned off.

Related thread on this issue:
https://forums.developer.apple.com/forums/thread/760964

Expected Behavior

Client being able to connect.

Additional Context

No response

Host Operating System

macOS

Operating System Version

15.0.1

Architecture

amd64/x86_64

Sunshine commit or version

v2024.1029.45450

Package

macOS - Homebrew

GPU Type

AMD

GPU Model

AMD RX 6800

GPU Driver/Mesa Version

OS Drivers

Capture Method

None

Config

encoder = videotoolbox
output_name = 4128836

Apps

I'm only using Desktop.

Relevant log output

[2024-10-30 01:07:15.619]: Info: // Ignore any errors mentioned above, they are not relevant. //
[2024-10-30 01:07:15.619]: Info: 
[2024-10-30 01:07:15.619]: Info: Found H.264 encoder: h264_videotoolbox [videotoolbox]
[2024-10-30 01:07:15.619]: Info: Found HEVC encoder: hevc_videotoolbox [videotoolbox]
[2024-10-30 01:07:15.619]: Info: Executing Do Cmd: [/Users/soeren/Documents/Projects/sunshine-scripts/start.sh]
[2024-10-30 01:07:22.014]: Info: Executing [Desktop]
[2024-10-30 01:07:22.189]: Info: New streaming session started [active sessions: 1]
[2024-10-30 01:07:22.748]: Error: opening microphone '' failed. Please set a valid input source in the Sunshine config.
[2024-10-30 01:07:22.748]: Error: Available inputs:
[2024-10-30 01:07:22.748]: Error: 	Built-in Input
[2024-10-30 01:07:22.748]: Error: 	BlackHole 16ch
[2024-10-30 01:07:22.748]: Error: 	WH-H900N (h.ear)
[2024-10-30 01:07:22.748]: Error: 	Built-in Line Input
[2024-10-30 01:07:22.748]: Error: Unable to initialize audio capture. The stream will not have audio.
[2024-10-30 01:07:32.259]: Info: 192.168.0.155: Ping Timeout
[2024-10-30 01:07:32.263]: Error: Initial Ping Timeout

[ReenigneArcher]

due to the frequent name change of the beta build

What do you mean by this? Specifically what name is changing?

[soerenkampschroer]

@ReenigneArcher the permission system tracks sunshine under the name of it's build for some reason. So if you update the beta build you need to give permissions all over again. For example for the Local Network permission it still lists "sunshine-v2024.1025" even though I have version v2024.1029.45450 installed. For every other permission (like screen recording) I'm getting a popup to allow it but I have only managed to get a popup once for Local Network. I've attached the settings screen you can see the old version is still there.

[ReenigneArcher]

Oh that makes sense.

@Hazer do you have some idea about how to solve this?

[soerenkampschroer]

I just had another go at it and I think I figured it out by accident. The linked Apple developer thread talks about "identifying responsible code" so I tried self signing the binary before launching sunshine and this time it did prompt me for all permissions including Local Network.

So the steps would be:

1. (optional) Uninstall sunshine
2. Remove all permissions granted to sunshine
3. Install sunshine-beta
4. Run codesign -s - --force --deep /usr/local/Cellar/sunshine-beta/2024.1029.45450/bin/sunshine (note the path will be different with every update)
5. Start the server, grant permissions
6. Connect a client and grant Local Network permissions

This will pollute the permissions screen a little, as you can't remove anything from there. I'm not sure if the OS will clear out old entries after a while, we'll see.

[ReenigneArcher]

Maybe create a symbolic link and grant the permission to that instead of the exact binary?

[soerenkampschroer]

When I was starting sunshine manually I just typed sunshine which points to a symlink in /usr/local/bin/sunshine => /usr/local/Cellar/sunshine-beta/2024.1029.45450/bin/sunshine. That's just how homebrew installs things. It will then show up as sunshine-v2024.XXXX. I don't know if that's different for the stable/release version, I just assumed it was a beta thing (can't test stable because of #3180 ).

Not sure what brew service uses, that might be something to look into. Maybe that's pointing directly to the binary.

But I'd imagine that macOS will follow symlinks to get to the binary anyway, otherwise couldn't you just steal permissions from another app by changing a symlink?

BTW: Thanks for your effort developing sunshine, it really is a great app! 👍

[ReenigneArcher]

I don't know if that's different for the stable/release version

It's unlikely to be different once we release stable.

[soerenkampschroer]

I poked around a little more, and the reason macOS recognizes Sunshine as a new app after each update is that the actual binary is named with the version included:

/usr/local/Cellar/sunshine-beta/2024.1029.45450/bin/sunshine-v2024.1029.45450

This is symlinked to sunshine in the same folder, which is then linked to /usr/local/bin/. So, macOS does follow symlinks, but it appears that to retain permissions, the binary needs to be named simply sunshine.

Additionally, the binary must be signed, either by you or the user; otherwise, the OS won’t prompt for permissions.

[ReenigneArcher]

The binary naming is all from homebrew, so there's nothing we can do about that as far as I know. And the version needs to be specified or else I believe homebrew won't understand when to do updates.

We could potentially add a step in homebrew to do the signing, which would effectively sign on the user's side. We don't actually publish macOS binaries, they are compiled by the user.

[soerenkampschroer]

@ReenigneArcher I managed to fix both signing and naming issues by editing the homebrew formula (sunshine-beta.rb).

To move the binary instead of symlinking it, you have to add a line right after calling make. Then to sign it, call codesign after that:

cd "build" do
  system "make"
  system "make", "install"
  
  # Move binary instead of symlinking it
  bin.install "sunshine-#{ENV["BUILD_VERSION"]}" => "sunshine"
  
  bin.install "tests/test_sunshine"
end

# Codesign installed binary
system "codesign", "-s", "-", "--force", "--deep", "#{bin}/sunshine"

It should then prompt for all permissions needed and keep them after updating as it shows up just as sunshine in the permission dialog.

[ReenigneArcher]

@soerenkampschroer Nice work! Would you mind making a PR? This is where we keep the homebrew formula template: https://github.com/LizardByte/Sunshine/blob/master/packaging/sunshine.rb

[ReenigneArcher]

I saw you forked our homebrew repo, to clarify the formula lives in the Sunshine repo, and is then synced over to the homebrew repo automatically.

[soerenkampschroer]

@ReenigneArcher right, thank you! I was just about to file the pull request.

Also, do you want me to only edit the formula for sunshine-beta or sunshine as well because I can't test the non-beta formula at the moment due to build errors. I can add the changes now or when the main build is able to compile to have it tested.

[ReenigneArcher]

I mean, you forked the wrong repo. The file to modify is in the URL I pasted above. So to update the "beta" you need to update it here in the Sunshine repo directly (not in the homebrew repo).

If you want you can also update the stable in the homebrew repo, but it's not really necessary as that package is not usable as far as I know.

[soerenkampschroer]

I created the pull request on the main repo. Please let me know if it checks out. I don't exactly understand how sunshine-beta.rb is created compared to the regular sunshine.rb as both need to eventually be edited but sunshine-beta.rb is the one that is currently an issue here.

[cathyjf]

The changing filename of the binary is not what is causing the permissions to need to be re-granted with each new build. See my other comment: #3348 (comment).

[soerenkampschroer]

Hey @cathyjf, you're right. I re-checked the permissions dialog in System Settings and now it's listing multiple "sunshine" entries. So I guess there is nothing we can do about that? I just read your comments on the pull request, thanks for clearing that up!

About the code signing thing: I wasn't aware that brew signs the build. But on my machine, unless you sign the binary yourself with codesign, the OS will not ask about Local Network permissions. Are you on macOS 15 and seeing different behavior? I'll install everything from scratch again tomorrow to make sure. Again, should have read your other comments first.

I'll keep the pull request open for the time being, just in case the codesign line does make a difference. But moving the binary doesn't do the trick, unfortunately.

Sorry about the confusion with the new pull request @ReenigneArcher, I'll make sure to just edit it next time.

[soerenkampschroer]

I did some more testing/research and homebrew is indeed only signing on arm64. This was fine up until macOS 15, because on x86 systems the new Local Network permission behaves like all the other permissions do on arm64, which is why homebrew started signing on arm64 in the first place (see apply_ad_hoc_signature ).

At least that is how I understood it. It seems like this is an issue that homebrew should address, surely sunshine is not the only package affected by this.

In the meantime, to make the build work on Intel Macs running macOS 15 I think it makes sense to include a platform specific codesign call in the formula.

[ReenigneArcher]

In the meantime, to make the build work on Intel Macs running macOS 15 I think it makes sense to include a platform specific codesign call in the formula.

I agree. We just need to check for architecture, in addition to the OS now.

[soerenkampschroer]

I've updated the pull request. It now includes the check for intel macs. I don't know much ruby, so please excuse if the code isn't up to standards. I've tested it on my machine, and it signs the binary for me with the edit I made.

I still have to start sunshine twice, even after signing. The flow is like this:

First run of brew services run sunshine-beta:

• asking for screen and audio recording permission
• client doesn't see the server

Second run:

• client sees server and on connect asking for File and Local Network permission
• client connects and works

That's the only caveat, but it is working now 🎉

[00Dchapellebot]

sudo rm -rf "$(brew --cache --build-from-source sunshine-beta)"

brew tap LizardByte/homebrew

brew install sunshine-beta

After successfully getting everything running I'm now experiencing a Similar Issue.

I'm wondering what the command is to 'update' sunshine-beta? // Or to uninstall it and remove permissions ?? (so I can install it again). After updating to Mac os sequoia, from Sonoma, now my WiiU client refuses to connect...to my Mac sunshine server. Apparently it's related to Local Network, privacy and security permissions in the new os (explained earlier)... where the first time you launch the Sunshine App it asks you to grant permission for Local network access... but if you have a previously installed version of sunshine with, an updated OSx it never asks for Local network permission, and Your client device Never connects...Again....Any Help? Thx in Advance!

[cathyjf]

Re: @00Dchapellebot, I can't determine what your problem is from what you're saying. However, unlike most permissions, there's no way that I know of to reset the state of the local network permission to force it to be re-prompted. (For example, you could force the Accessibility permission to be re-prompted using tccutil reset Accessibility, but there's no similar feature for local networking.) I don't think your problem is caused by not being able to reset this permission, however.

What steps have you taken to narrow down that the problem in your case is caused by the local network permission? There are a lot of other reasons that the client might not be able to connect.

You can uninstall a brew formula with brew uninstall sunshine-beta, if that is what you are asking. Or you can use brew update to update. I'm not sure these are related to your problem either, but you did ask about it.

[cathyjf]

To help figure out if the local network permission is actually the culprit, try directly running the binary in the foreground of your shell in Terminal.app (rather than using a background service). The local network permission shouldn't be required for processes run in this way.

[cathyjf]

I'm now noticing a problem on my machine where sunshine can access the local network, regardless of whether it is granted local network permission! What this suggests to me is that this setting is buggy. A review of the documentation, and posts from Apple employees on Apple's forums, implies that the feature works best for app bundles, rather than loose binaries like Sunshine. This part of the bug is tracked at https://github.com/orgs/LizardByte/discussions/547.

Separately, another part of the problem may be missing fields in the Info.plist file. I opened https://github.com/orgs/LizardByte/discussions/549 to track that part of the bug.

[soerenkampschroer]

Same here, today's update broke connectivity for me. With v2024.1101.204249 the server is not visible on the client. Logs are fine, no errors. Running in the foreground makes no difference.

I think the last build that I had working was the one before v2024.1101, but I can't remember what it was, and the tag is gone now. The issue may have been introduced in the last two builds.

[soerenkampschroer]

It doesn't look like an issue regarding Local Network permissions, because with that the client was able to see the server but not connect and there was an error in the logs. Must be something else.

[cathyjf]

If running in the foreground makes no difference, it theoretically shouldn't be related to the local network permission, but as I said, my own tests establish that that permission is buggy, so who knows.

[cathyjf]

It doesn't look like an issue regarding Local Network permissions, because with that the client was able to see the server but not connect and there was an error in the logs. Must be something else.

This is not necessarily conclusive because only some local network operations actually require the permission. For example, incoming TCP connections supposedly do not require it.

One thing I'm concerned about is that your fix to invoke codesign manually might not work correctly if a previous binary at the same inode was signed in the past. Homebrew's codesigning has a workaround for that issue, but of course we're not using it here. On arm64, code that is not correctly signed won't run at all, and although that's not the case on Intel, who knows what unusual issues it might cause.

Everything is still working fine for me on my arm64 mac machine on the latest commit (03253fc).

[soerenkampschroer]

@cathyjf I misread your previous post thinking you are now having trouble connecting, but I see now it's actually the opposite. Maybe it's just an issue on my end, I'll look into it.

The same inode should only be a problem if you reinstall the same version though, wouldn't it? The path changes with every version. And reinstalling hasn't led to any more problems for me. But the manual signing should only be a stopgap until it's properly signed like you said or brew updates it's signing logic.

The permission is (or was?) buggy for sure. Before I opened this issue, I saw a lot of complaints about this in multiple different places. Not being able to add or remove anything manually certainly doesn't help. Some of the issues appear to have been resolved in previous beta builds (like in one of the threads you posted in the separate discussion), so it's a bit difficult to get a sense of what the current state of it is.

Can I ask you something unrelated to this issue: When you disconnect your client from your macOS sunshine server, does sunshine spike to 100% CPU usage on your machine? It's not entirely crashing as I can just stop the service and start it again, but once I've disconnected the client it stays at 100% usage and I can't connect again until I restart the server.

[soerenkampschroer]

It's working now, it was the client on my tablet that was causing the connection issue.

[00Dchapellebot]

@cathyjf Hey, I tried running sunshine beta as a foreground process....NOt sure if it makes a difference moving a process to the foreground vs Starting a process in the foreground in shell... I'm not familiar with homebrew: So What is the command to start sunshine-beta this way/ in foreground? My Wiiu client is still not connecting after 'moving' the process to foreground .....

As far as narrowing down why my wiiU client which formally worked on Mac Sonoma three days ago and then stopped working after the upgrade to Sequoia...I am at a complete loss. Everything worked...I was running Hogwarts Legacy through Gameporting toolkit ...On Mac Sonoma ...streaming through Sunshine-beta ... playing on WiiU tv ... Then I wanted to take advantage of GPTK2 beta with support for ray tracing and other things....This works with the New OS Sequoia.... So I did those upgrades, everything runs fine ... Hogwarts looks great.... OS Sequoia, GPTK2....and now WiiU client cannot reach my sunshine-beta.... with error " Can't connect to server "

Moonlight on my iPhone 6s works/ And connects ....to sunshine beta on my sequoia...without issue .... So Maybe it's NOT the local networks permissions, except that my WiiUclient worked and connected perfectly up until the OS upgrade...

(because my client never reaches the server... I no longer get a prompt to PAIR the client device?)

In terms of trying to get the re-prompt for local network permissions on Mac Sequoia, And initializing a beta update, I've tried :

brew uninstall sunshine-beta : this returns " Error: No such keg: /usr/local/Cellar/sunshine-beta. "

brew reinstall sunshine-beta : Returns the proper current tag v2024.1101.204249, then terminal runs cmake and it builds .... but when I launch sunshine it still tells me I still have my old version : Version v2024.911.215654 ??

(so why didn't it build the version it identified?)

brew upgrade sunshine-beta : returns .......Error: lizardbyte/homebrew/sunshine-beta not installed

brew update ...runs and lets me know " Already up-to-date." ...?

Thanks again, for the advice, really appreciate it!

[soerenkampschroer]

@00Dchapellebot sounds like you had an older non-beta version of sunshine installed before upgrading. Try running:
brew uninstall sunshine and brew uninstall sunshine-beta and then run brew update and brew upgrade.

Now do brew install sunshine-beta and start it in the foreground (by typing sunshine not sunshine-beta in the terminal). Note that on my machine if using it as a service, I have to start and stop it twice for it to ask for all relevant permissions.

If your iPhone can connect to your old sunshine install, this likely won't fix your problem with the WiiU. If your sunshine install has the problem mentioned in this issue then it will not be able to connect at all, regardless of the client.

[00Dchapellebot]

@soerenkampschroer that's sort of what I was thinking, thanks for the commands!... I can connect to sunshine through two local moonlight clients, (Apple 6s and on Wii U). So I think you're right and it's related to the Client side WiiU app and not to the Mac OSX Sequoia running sunshine-beta (it's just that immediately after doing the sequoia updated...with its new local permissions, the client stopped connecting) Reinstalling the client side program on the wiiU still doesn't fix the issue. But everything else seems good. Thanks again.

[soerenkampschroer]

@00Dchapellebot See issue #3180, not sure if there is a fix yet.

[bitxeno]

macOS 15.1 with Apple silicon also can not been connected from lan. I have try reinstall but also failed.

[bitxeno]

I made a simple Mac app wrapper for sunshine, this can fix my LAN connection issues. It might be due to the service permission limits in macOS 15.

https://github.com/bitxeno/sunshine-mac

[djtwxj]

macos15,sunshine-beta
start service for a while, will consume all disk space . only restart macos, the lost disk space will come back

[ReenigneArcher]

That's kind of odd. Sunshine doesn't even really use disk other than to write the certificates and config files.

[djtwxj]

donot know why. if start sunshine-beta service and connect with moonlight for a while. then close moonlight, just leave sunshine running for a longtime( 12 hrs), the disk space will used up. and u have to stop sunshine-beta service,and restart macos, the lost disk space will come back

Macos15 , M4 MINI

[00Dchapellebot]

@soerenkampschroer, I solved that thread Issue #3180 .
It turned out to be the reason brew uninstall commands were failing. In terms of Sunshine not connecting to WiiU Client post Mac sequoia upgrade.... My problem was NOT "Local Network Permissions" it was due to... third party Moonlight WiiU client requiring the user to input a 'static' IP address. The LAN adapter I was using on server Side to connect ethernet, Changes its IP address periodically ...BLocking smooth streaming...