Warum macOS Sequoia openrsync nutzt und was das fuer Remote-Build-Sync bedeutet
Apple hat in macOS Sequoia den lange genutzten rsync durch openrsync ersetzt; Gruende haengen vor allem mit der GPLv3-Lizenzpolitik zusammen. Der mitgelieferte rsync 2.6.9 ist veraltet, rsync 3.x ist GPLv3 – Apple setzt auf die BSD-lizenzierte openrsync, um Lizenz- und Vertriebsauflagen zu umgehen. Fuer Entwickler ist openrsync schlanker und schneller, verhaelt sich bei Remote-Daemon-Modus (rsync daemon), ACL und Teilen der Rechte-Synchronisation aber anders als rsync 3.x. Wenn eure Pipeline darauf angewiesen ist, solltet ihr vorher klaeren: entweder weiter Homebrew-rsync 3.x nutzen oder openrsync-Grenzen akzeptieren und Skripte anpassen.
Beim Remote-Build-Sync wirkt sich das vor allem auf drei Dinge aus: Kompatibilitaet von Inkrement-Checks und Delta-Uebertragung, wie gut Rechte und Timestamps am Ziel erhalten bleiben, und Kompatibilitaet mit bestehenden rsync-Befehlen in CI (z. B. GitHub Actions, Jenkins). Bei reiner „lokaler zu Remote-Verzeichnis“-Synchronisation reicht openrsync oft; sobald Daemon-Modus, komplexe ACL oder Multi-Node-Sync im Spiel sind, solltet ihr beim vollstaendigen rsync bleiben.
rsync vs openrsync: Rechte, ACL, Remote-Daemon
Uebersicht ueber fuer Remote-Build-Sync relevante Faehigkeiten – System-openrsync vs. Homebrew rsync 3.x.
| Faehigkeit | System openrsync (Sequoia) | Homebrew rsync 3.x | Auswirkung auf Build-Sync |
|---|---|---|---|
| Inkrement / Delta | ja | ja | Beide koennen Inkrement-Sync, kaum Unterschied |
| Remote-Daemon | eingeschraenkt/abweichend | voll | Wenn CI ueber rsync:// Artefakte holt: Homebrew rsync |
| ACL / erweiterte Attribute | teilweise | voll | Strenge Rechte-Beibehaltung: rsync 3.x |
| --fake-super | geplant (openrsync Roadmap) | ja | Relevant wenn non-root volle Rechten behalten soll |
| Wartung / Update | mit OS | brew upgrade rsync | Langfristig flexibler mit Homebrew |
Fazit: Nur „Lokal/CI nach Remote-Mac-Verzeichnis“-Inkrement-Push ohne Daemon und komplexe ACL? Dann zuerst System-openrsync ausprobieren. Sonst auf Build-Knoten einheitlich brew install rsync und explizit /opt/homebrew/opt/rsync/bin/rsync oder PATH so setzen, dass nicht der System-openrsync genutzt wird.
Empfohlene Setups: Homebrew rsync / Docker rsync / SFTP
Drei gaengige Varianten und wann sie passen.
- Homebrew rsync: Auf Remote Mac
brew install rsync, CI oder lokal per SSH diesen rsync aufrufen. Passt, wenn SSH-Zugang standardisiert ist und volle rsync-Funktionalitaet gewuenscht ist. PATH so, dass Homebrew-Version vor System-openrsync kommt. - Docker rsync: Auf Remote Mac rsync 3.x im Container betreiben – Version und Verhalten bleiben fix. Sinnvoll bei gemischten Multi-Node-/Multi-OS-Umgebungen, erhoeht aber Aufwand fuer Images und Netzwerk.
- SFTP-Gateway + Verzeichnis-Trennung: Ohne rsync-Daemon ueber SFTP Build-Artefakte hoch-/runterladen, mit klaren Verzeichnis-Rechten und Audit. Passt, wenn Rechte-Grenzen, Audit und Multi-Rollen-Auslieferung wichtiger sind; bei Bedarf Inkrement-Sync in „erlaubten“ Verzeichnissen per rsync over SSH darueber.
In der Praxis nutzen viele Teams eine Kombination: SFTP fuer Zugang und Rechte, rsync fuer grosse Inkrement-Syncs – SFTP stellt sicher, dass nur berechtigte Konten auf definierte Verzeichnisse zugreifen, rsync uebernimmt effiziente Inkrement-Uebertragung darin.
ENOSPC, ECONNREFUSED und andere haeufige Sync-Fehler
Fuenf Schritte zur Eingrenzung und Loesung.
# 1. Welchen rsync nutzt ihr (Vermischung mit openrsync vermeiden)
which rsync
/opt/homebrew/bin/rsync --version
# 2. SSH und Ziel-Plattenplatz pruefen (ENOSPC vermeiden)
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest" # Inodes voll?
# 3. Pruefen ob Ziel lauscht (ECONNREFUSED vermeiden)
# Bei rsync-Daemon: netstat -an | grep 873
# Bei rsync over SSH: sshd laeuft, Firewall erlaubt 22
# 4. Trockenlauf – was wuerde uebertragen
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/
# 5. Echter Lauf mit Log
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log
ENOSPC: Ziel-Platte oder Inodes voll – Ziel aufraeumen, alte Artefakte archivieren oder Kapazitaet erweitern; optional in CI „vor Sync Plattenplatz pruefen“ einbauen.
ECONNREFUSED: Gegenseite hoert nicht oder Firewall – bei SSH sshd und Port 22 pruefen, bei rsync-Daemon Port 873 und rsyncd.conf.
Permission denied / Rechte: Ziel-Verzeichnis-Owner muss zum SSH-User passen; bei Bedarf ACL/--fake-super – fuer vollstaendige Rechte-Beibehaltung Homebrew rsync und Doku nutzen.
Entscheidungs-Checkliste: rsync/openrsync vs. SFTP-Hosting nach Team und OS
- Nur eine Maschine / ein Node, Sequoia-openrsync reicht: System-rsync nutzen, in Skripten keinen Daemon und keine komplexen ACL verwenden.
- Multi-Node-CI, Daemon oder strenge Rechten noetig: Auf allen Knoten Homebrew rsync installieren und Pfad fest verwenden.
- Rechte-Grenzen, Audit, Multi-Rollen-Auslieferung wichtig: SFTP-Gateway und Verzeichnis-Trennung einfuehren, in erlaubten Verzeichnissen ggf. rsync over SSH.
- Weniger Abhaengigkeit von Einzelmaschine und rsync-Version: Build-Artefakt-Hosting an einen Remote-Mac-Hosting-Anbieter mit SFTP abgeben – der stellt Verfuegbarkeit und Rechte-Policy sicher, lokal/CI nur Upload/Download und Pruefung.
rsync und openrsync decken die meisten „Verzeichnis-Inkrement-Sync“-Faelle ab; entscheidend sind einheitliche Version, konsistenter Pfad und schnelle Fehlereingrenzung. Wenn Teams wachsen und Compliance/Audit-Anforderungen steigen, reicht rsync allein oft nicht – dann braucht es eine klare Zugangsschicht (z. B. SFTP) und eine stabile Remote-Umgebung.
Warum hat macOS Sequoia den systemeigenen rsync durch openrsync ersetzt?
Wegen GPLv3-Lizenzkonflikten mit Apple-Richtlinien hat Apple in macOS Sequoia den bisherigen rsync durch die BSD-lizenzierte openrsync ersetzt. openrsync ist schlanker und performanter, verhaelt sich bei Remote-Daemon-Modus, ACL und Teilen der Rechte-Synchronisation aber anders als rsync 3.x – bei Remote-Build-Sync ist Kompatibilitaet zu beachten.
Rsync oder SFTP fuer Build-Artefakt-Sync auf Remote Mac?
Wenn das Team bereits rsync einheitlich nutzt und Inkrement plus Checksummen braucht, kann Homebrew rsync 3.x weiter genutzt werden. Bei Fokus auf Rechte-Grenzen, Audit und Multi-Rollen-Auslieferung ist ein SFTP-Gateway mit Verzeichnis-Trennung oft einfacher zu betreiben. Beides kann kombiniert werden: SFTP fuer Zugang und Rechte, rsync fuer grosse Inkrement-Syncs.
ENOSPC oder ECONNREFUSED beim Sync – wie eingrenzen?
ENOSPC bedeutet Ziel-Platte oder Inodes voll – Ziel aufraeumen oder erweitern. ECONNREFUSED bedeutet Gegenseite hoert nicht oder Firewall blockiert – sshd, rsync-Daemon bzw. SFTP-Port und Netz/Firewall zwischen lokalem und Remote-Mac pruefen.
Rsync-/openrsync-Versionen und Netz-/Platten-Fehler auf eigenen Macs oder CI-Knoten zu pflegen kostet Zeit. Wenn ihr euch lieber auf die fachliche Auslieferung konzentrieren wollt, koennt ihr Build-Sync und Rechte-Steuerung einem Remote-Mac-Hosting ueberlassen: SFTPMAC bietet stabiles SFTP und Verzeichnis-Trennung, kompatibel mit rsync-over-SSH-Inkrement-Sync – wir kümmern uns um Verfuegbarkeit und Rechte-Policy, ihr um Build und Release.