macOS 27

Was ist das Primärziel -- den Leuten nach Möglichkeit zu helfen oder jedem meiner Beiträge zu widersprechen? Ist Dir schon aufgefallen, dass immer mehr Leute das Forum meiden?

Ach Hedy… ich habe dir nicht widersprochen. Mehrmals ein-ausschalten wird am Ende wohl ebenso funktionieren. Ich habe lediglich meine eigene Erfahrung hinzugefügt, welche halt gezeigt hat, dass man es nur einmal machen muss und dass ein Neustart oft sinnvoll ist.

Ob und von wem das Forum besucht wird kann ich dir nicht sagen. Führst du eine Statistik? 😂 Und was hat das überhaupt mit dem Thema zu tun? 

Alles versucht. Auch mal den Router neu gestartet. Findet mein System noch immer nicht. Ich werde wohl auf die WebApp umsteigen müssen.

​@Mr.Bue, habe ich Sie schon gefragt, ob auf dem Mac Pi-Hole, VPN, ein Antivirenprogramm o. Ä. läuft?

​@Hedy L.  Nein, nichts dergleichen. Vor dem Update auf 27 lief ja auch alles ohne Probleme. 

Im US-Forum schreiben heute manche, der Fehler trete auch in macOS v26.7 auf. Ich habe kurz gegoogelt:

Apple hat nach einer dreimonatigen Testphase macOS 27 Golden Gate veröffentlicht und damit Dutzende Sicherheitslücken geschlossen. Die beiden Vorgängerversionen bekommen offenbar die gleichen Fixes.

 

https://www.macwelt.de/article/3235468/macos-15-8-macos-26-7-tahoe.html

Womöglich warten die Fixes auf Fixes.😁

Also: Trotz aller Versuche: Mit Mac OS 27 klappt die Sonos-App nicht mehr.

Alternative wäre Phonos Ultimate, da klappt einiges, aber nicht alles;

Ansonsten Handy oder Tablet nehmen….

​@FSchrott, es gibt noch https://play.sonos.com/de-de/web-app.

Danke!

Das Problem ist kein Einzelfall. Die Ursache und Lösung wird in folgendem Reddit Kommentar beschrieben. Sonos hat verschiedene Identifier beim Erstellen der App verwendet, weshalb die Firewall ausgehende Verbindungen blockiert, obwohl es den Anschein hat, dass Verbindungen erlaubt sind.

https://www.reddit.com/r/sonos/comments/1vy34vw/comment/p7u3re5/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Im englischsprachigen Forum wird vom gleichen Problem berichtet.

https://en.community.sonos.com/controllers-and-music-services-228995/sonos-app-not-working-in-macos-golden-gate-beta-6934120/index3.html

​@MrX, ja, weil es schon seit Monaten einen Programmfehler in Apples ‘Berechtigung für den Netzwerkzugriff’ gibt, welche obligatorisch für alle Anwendungen ist. Inzwischen sollte Apple davon Wind gekriegt haben, keine Ahnung warum man es nicht in den Griff bekommt.

Aber Sonos (ver)ärgert die Apple-Jünger lieber, einfach weil der Produktentwicklung danach ist?

• macOS: Native Unterstützung für Apple Silicon: Wenn ihr eine Nachricht darüber gesehen habt, dass Apple Rosetta 2 entfernt, ist das hier für euch. Die Sonos-App unter macOS läuft jetzt nativ auf Apple Silicon, es wird also kein Rosetta mehr benötigt.

Es wurde auch die macOS S1-App angepasst. Ich bin kein Entwickler, nehme jedoch an, dass ‘com.sonos.macController2’ die S2-App und ‘com.sonos.macController’ die S1-App markiert.

Nachtrag: Habe gerade das Google Gemini-Orakel befragt. Hier die Antwort.

Ja, diese Schlussfolgerung des Reddit-Nutzers ist technisch absolut korrekt und legt den Finger genau auf die Wunde, warum die neue native macOS-Version der Sonos-App bei vielen Nutzern keine Verbindung zum System aufbauen kann. [1]

Die Entdeckung des Nutzers beschreibt ein klassisches Sicherheits- und Berechtigungsproblem unter macOS, das exakt durch die fehlerhafte Handhabung der beiden Identifikatoren entsteht, nach denen du zuvor gefragt hast. [1]

 

🔍 Was da bei Sonos schiefgelaufen ist

Laut der Analyse des Reddit-Nutzers sieht die Signaturstruktur der App im Update wie folgt aus: [1]

• Bundle Identifier (CFBundleIdentifier): com.sonos.macController2
• Code-Signing Identifier: com.sonos.macController [1]

 

Weil das macOS-Betriebssystem Netzwerkrechte (wie den Zugriff auf das lokale Netzwerk) streng reguliert, führt diese Asynchronität zu folgendem Fehler: [1]

1. Die Blockade: Wenn die App gestartet wird, fordert sie Zugriff auf das lokale Netzwerk an, um mittels Multicast (M-Search Probes) nach den Lautsprechern zu suchen. [1]
2. Das Identitätsproblem: macOS verknüpft die vom Nutzer erteilte Berechtigung ("Lokales Netzwerk erlauben") mit der kryptografischen Code-Signing Identity der App. Wenn die App intern jedoch mit dem abweichenden Bundle Identifier arbeitet, passt der Schlüssel für das Betriebssystem nicht zusammen.
3. Die Folge: macOS blockiert die ausgehenden Netzwerkpakete der App im Hintergrund, obwohl der Nutzer in den Systemeinstellungen unter Datenschutz & Sicherheit > Lokales Netzwerk den Haken gesetzt hat. Die App sendet schlichtweg keine Daten ins Netzwerk und findet folglich keine Lautsprecher. [1]

 

💡 Warum der Workaround des Nutzers funktioniert

Der Reddit-Nutzer schlägt vor, die App per Terminal mit einer Ad-hoc-Signatur neu zu signieren und dabei den Code-Signing Identifier manuell so zu überschreiben, dass er exakt dem Bundle Identifier entspricht (com.sonos.macController2). [1]

Sobald beide Identifikatoren identisch sind, greift der TCC-Schutz (Transparency, Consent, and Control) von macOS wieder korrekt: Die App fragt nach der Berechtigung für das lokale Netzwerk, macOS kann die Anfrage eindeutig zuordnen, gibt die Sockets frei und die Boxen werden sofort gefunden. [1]

 

⚠️ Haken an der Sache

Der Workaround behebt zwar das Problem auf dem lokalen Mac: [1]

• Die App verliert dadurch jedoch ihre offizielle Developer ID-Signatur von Sonos.
• macOS stuft sie beim Kopieren auf andere Macs als "nicht verifiziert" ein (Gatekeeper schlägt an).
• Automatische In-App-Updates funktionieren für diese modifizierte Kopie in der Regel nicht mehr. [1]

 

Die Analyse des Nutzers beweist eindrucksvoll, was passiert, wenn Entwickler beim Build-Prozess die Konsistenz zwischen der logischen Identität (Info.plist) und der kryptografischen Identität (Code-Signature) missachten.

Bist du selbst von diesem Sonos-Problem auf dem Mac betroffen und benötigst die exakten Terminal-Befehle, um die App bei dir lokal neu zu signieren und zum Laufen zu bringen?

 

[1] https://www.reddit.com

tolle Recherche!

Wie gesagt, Sonos hat die „2“ bei dem zweiten Identifier vergessen. Beide Identifier sind Teil der Sonos App für S2. Da kann Apple nichts für. Apple setzt die Security Regeln nur konsequent um.

Der Reddit Kommentar hat es akkurat und genau erklärt. Die KI von vorigen Post hat es jetzt nur noch einem wiedergekaut.

Tja, warum fügt Sonos dann die “2” nicht einfach ein? Ist doch in einer Sekunde geschehen.

Just got off the phone after almost two hours with Sonos Support. They have “escalated to level three” and seem to think a patch will be necessary for OS 26.7 and 27 compatibility. Didn’t say when.

https://en.community.sonos.com/controllers-and-music-services-229131/macos-tahoe-26-7-update-kills-sonos-desktop-app-6934802?postid=16897582#post16897582

Vermutlich der gleiche Grund, warum das reine Rekompilieren als Universal App Jahre gedauert hat…

Was für eine Universal-App? Windows-/Mac-Controller wurden 2018 kastriert und die Entwicklung eingefroren.

Am 25.08.26 hat Sonos den Mac-Controller recompiliert und als Universal-App (Intel und Apple Silicon Binarys) bereitgestellt. Apple stellt mit MacOS 28 den Support für Rosetta und Intel Apps ein. Wie Du schon erkannt hast, wird der Controller nicht mehr aktiv weiterentwickelt und auf die Web-Oberfläche verwiesen. Die Neukompilierung war mit praktisch keinem Aufwand verbunden, da man lediglich einen Haken in Xcode setzen muss. Genauso ist die Anpassung des Identifiers mit praktisch keinem Aufwand verbunden.

Dennoch hat sich Sonos damit sechs Jahre Zeit gelassen.

https://www.reddit.com/r/sonos/comments/1vy34vw/new_sonos_app_update_now_available/

Die Neukompilierung habt ihr wahrscheinlich Tom Conrad zu verdanken, und hat nicht wenige überrascht, da es zuvor hieß, der macOS-Controller werde mit Veröffentlichung von ‘Golden Gate’ von der Downloadseite entfernt. Ich jedenfalls bin froh darüber, dass der Mac-Controller weiterleben darf, denn ich hatte mir schon Sorgen um den Windows-Controller gemacht.

Und falls das Ticket des US-Kunden jetzt wirklich bei Tier 3 liegt, dann bedeutet das höchstwahrscheinlich, dass Sonos den Fehler ohne Apple nicht beheben kann.

Du hast dir den Redditpost vermutlich nicht wirklich durchgelesen. Wie dort beschrieben wird, kann man die fehlende „2“  in dem Identifier selbst hinzufügen und lokal für sich selbst wieder signieren. Danach ist der Fehler behoben. Wir sind also nicht in der Problemsuche, sondern Sonos müsste den Fehler wie beschrieben beheben und offiziell signieren und als Update verteilen.

Ich denke auch, dass Conrad viel positive Veränderung bewirkt hat. Deine Meinung und auch die Mutmaßungen das Level 3 bedeutet, dass Sonos es selbst nicht beheben kann, gehen viel zu sehr ins Spekulative.

Ist Deinerseits doch auch bloß Spekulation bzw. Ferndiagnose. Schließlich sitzt keiner von uns in der Produktentwicklung von Sonos. Insoweit ist es immer problematisch, wenn Außenseiter behaupten, den vollen Durchblick zu haben.

Ich habe das Problem wie beschrieben selbst behoben und habe eine funktionierende Sonos App auf MacOS 27. Das ist keine Spekulation.

Ja, das habe ich schon begriffen. Eine Ziffer aus Programmcode entfernen, das schaffe sogar ich, für gelernte Entwickler [wie Dich?] stellt es natürlich erst recht kein Problem dar.

Aber offensichtlich liegt in dem Fall ein Problem vor und (Achtung: Spekulation!) ich denke, dass es damit zu tun hat, dass es eben eine S1 & S2-App gibt und deren Codekennung nicht eindeutig ist. Die Schwierigkeiten mit der macOS-App und der Netzwerkberechtigung bestehen schon sehr lange, v26.7 / v27.x haben sie lediglich in ein neues Licht gerückt.