Why 2026 macOS Sequoia uses openrsync and what it means for remote build sync
Apple replaced the long-standing system rsync with openrsync in macOS Sequoia, mainly due to GPLv3 licensing. The bundled rsync 2.6.9 was outdated; modern rsync 3.x is GPLv3, so Apple adopted the BSD-licensed openrsync. For developers, openrsync is smaller and faster but differs from rsync 3.x in daemon mode, ACLs, and some permission semantics. If your pipeline depends on those, you must either keep using Homebrew rsync 3.x or adapt scripts to openrsync’s behavior.
For remote build sync, impact falls into three areas: delta transfer and checksum compatibility, how well permissions and timestamps are preserved on the destination, and compatibility with existing CI (e.g. GitHub Actions, Jenkins) rsync usage. For simple “local directory to remote directory” sync, openrsync is often enough; for daemon mode, complex ACLs, or multi-node sync, stick with full rsync.
rsync vs openrsync: permissions, ACLs, and daemon mode
This table compares system openrsync (Sequoia) with Homebrew rsync 3.x for typical remote build sync needs.
| Feature | System openrsync (Sequoia) | Homebrew rsync 3.x | Impact on build sync |
|---|---|---|---|
| Incremental / delta | Yes | Yes | Both suit incremental sync |
| Remote daemon mode | Limited or different | Full | Use Homebrew rsync if CI pulls via rsync:// |
| ACL / extended attributes | Partial | Full | Use rsync 3.x when you need strict permission preservation |
| --fake-super | Planned (openrsync roadmap) | Yes | Needed for non-root full permission preservation |
| Updates | With OS | brew upgrade rsync | Homebrew gives more control long-term |
Bottom line: if you only push from CI or local to a remote Mac directory and do not rely on daemon or complex ACLs, try system openrsync first. Otherwise install brew install rsync on build nodes and call /opt/homebrew/opt/rsync/bin/rsync (or ensure it is first in PATH) so you do not mix system openrsync with full rsync.
Recommended approaches: Homebrew rsync, Docker rsync, SFTP
Three common options and when to use them.
- Homebrew rsync: On the remote Mac run
brew install rsync; CI or your machine uses that rsync over SSH. Best when SSH access is standard and you want full rsync behavior. Ensure PATH prefers the Homebrew binary so it is not mixed with system openrsync. - Docker rsync: Run rsync 3.x in a container on the remote Mac for consistent versioning and isolation from OS changes. Suits mixed nodes and OSes but adds image and network management.
- SFTP gateway and directory isolation: No rsync daemon; upload and download build artifacts via SFTP with strict directory permissions and audit. Best when permission boundaries and compliance matter; you can still use rsync over SSH inside allowed directories for incremental sync.
Many teams combine SFTP for access control with rsync for bulk incremental sync: SFTP enforces who can access which directories, rsync handles efficient transfer inside those directories.
ENOSPC, ECONNREFUSED and other common sync failures
Five-step troubleshooting flow.
# 1. Confirm which rsync is used (avoid mixing with openrsync)
which rsync
/opt/homebrew/bin/rsync --version
# 2. Check SSH and destination disk (avoid ENOSPC)
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest" # inode exhaustion
# 3. Verify remote is listening (avoid ECONNREFUSED)
# For rsync daemon: netstat -an | grep 873
# For rsync over SSH: ensure sshd is up and firewall allows 22
# 4. Dry run to see transfer list
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/
# 5. Run and log
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log
ENOSPC: Destination disk or inode full. Free space, archive old artifacts, or expand storage; add a “check disk before sync” step in CI if needed.
ECONNREFUSED: Remote not listening or blocked. For SSH, check sshd and port 22; for rsync daemon, check port 873 and rsyncd.conf.
Permission denied: Confirm destination ownership and SSH user; if you need full permission preservation, use Homebrew rsync and its docs for ACL/--fake-super.
Decision checklist: rsync/openrsync vs SFTP hosting
- Single machine or node, system openrsync is enough: Use system rsync and avoid daemon and complex ACLs in scripts.
- Multi-node CI, daemon or strict permissions: Install Homebrew rsync on each node and use its path explicitly.
- Permission boundaries and audit matter: Add an SFTP gateway and directory isolation; use rsync over SSH only inside allowed directories if needed.
- Reduce dependence on per-machine rsync version: Move build artifact hosting to an SFTP-hosted remote Mac service so availability and permissions are managed for you; local or CI only uploads, downloads, and verifies.
Both rsync and openrsync work for many “directory incremental sync” cases; what matters is consistent versioning, clear paths, and fast troubleshooting. As teams and compliance requirements grow, rsync alone is rarely enough—you need a clear access layer (e.g. SFTP) and a stable remote runtime.
Why did macOS Sequoia replace system rsync with openrsync?
Apple switched to BSD-licensed openrsync in macOS Sequoia due to GPLv3 licensing. openrsync is smaller and faster but differs from rsync 3.x in daemon mode, ACLs, and some permission behavior; remote build sync setups should verify compatibility or use Homebrew rsync.
For remote Mac build sync, is rsync or SFTP better?
Use Homebrew rsync 3.x when you need full incremental and checksum behavior; use an SFTP gateway with directory isolation when you need clear permission boundaries and auditability. Many teams use both: SFTP for access control, rsync over SSH for bulk incremental sync.
How do I troubleshoot ENOSPC and ECONNREFUSED during sync?
ENOSPC means the destination disk or inode is full—free space or expand storage. ECONNREFUSED means the remote service is not listening or is blocked by firewall; check sshd, rsync daemon port, or SFTP port and network rules between your machine and the remote Mac.
Maintaining rsync/openrsync versions and debugging network and disk issues on self-managed Mac or CI nodes takes time. If you prefer to focus on delivery, consider delegating build sync and access control to a hosted remote Mac: SFTPMAC provides stable SFTP and directory isolation, works with rsync over SSH for incremental sync, and handles availability and permissions so you can focus on builds and releases.