為什麼 2026 年 macOS Sequoia 要用 openrsync，對遠端建置同步有什麼影響
Apple 在 macOS Sequoia 中用 openrsync 替代了沿用多年的 rsync，主要原因與 GPLv3 許可策略有關。系統自帶的 rsync 2.6.9 年代久遠，而新版 rsync 3.x 採用 GPLv3，蘋果選擇引入 BSD 許可的 openrsync 以規避合規與分發限制。對開發者而言，openrsync 體積更小、效能有優化，但在遠端守護模式（rsync daemon）、ACL 及部分權限同步行為上與 rsync 3.x 存在差異，若你的流水線依賴這些特性，就需要提前評估：要麼繼續使用 Homebrew 安裝的 rsync 3.x，要麼接受 openrsync 的功能邊界並調整腳本。
遠端建置同步場景下，影響主要集中在三方面：一是增量校驗與 delta 傳輸的相容性，二是目標端權限與時間戳的保留程度，三是與現有 CI（如 GitHub Actions、Jenkins）中 rsync 指令的相容性。多數「只做本機到遠端目錄同步」的用法，openrsync 可以勝任；一旦涉及 daemon 模式、複雜 ACL 或跨多節點同步，建議仍使用完整版 rsync。
rsync 與 openrsync 功能對比表：權限、ACL、遠端守護模式差異
下表從遠端建置同步常用能力出發，對比系統 openrsync 與 Homebrew rsync 3.x，便於你按需選型。
| 能力 | 系統 openrsync (Sequoia) | Homebrew rsync 3.x | 對建置同步的影響 |
|---|---|---|---|
| 增量 / delta 傳輸 | 支援 | 支援 | 兩者均能滿足增量同步，差異不大 |
| 遠端 daemon 模式 | 有限或行為差異 | 完整支援 | 若 CI 透過 rsync:// 拉取產物，建議用 Homebrew rsync |
| ACL / 擴充屬性 | 部分支援 | 完整支援 | 需嚴格保留權限時選 rsync 3.x |
| --fake-super | 計劃中 (openrsync 路線圖) | 支援 | 非 root 保留 full permissions 時依賴此項 |
| 維護與升級 | 隨系統更新 | brew upgrade rsync | 長期可控性 Homebrew 更靈活 |
結論：若僅做「本機或 CI 到遠端 Mac 目錄」的增量推送、且不依賴 daemon 與複雜 ACL，可先嘗試系統 openrsync；否則建議在建置節點上統一安裝 brew install rsync，並顯式使用 /opt/homebrew/opt/rsync/bin/rsync 或 PATH 優先，避免與系統自帶的 openrsync 混用。
遠端 Mac 上建置產物同步的推薦方案（Homebrew rsync / Docker rsync / SFTP）
三種常見做法的適用場景與注意點如下。
- Homebrew rsync： 在遠端 Mac 上執行
brew install rsync，CI 或本機透過 SSH 呼叫該 rsync。適合已標準化 SSH 存取、且希望保留完整 rsync 能力的團隊。注意確保 PATH 中優先使用 Homebrew 版本，避免與系統 openrsync 混用。 - Docker rsync： 在遠端 Mac 上以容器執行 rsync 3.x 服務，保證版本一致、不受系統變更影響。適合多節點、多系統混雜的環境，但需要維護映像與網路對應，複雜度較高。
- SFTP 閘道 + 目錄隔離： 不依賴 rsync daemon，透過 SFTP 上傳/下載建置產物，配合嚴格目錄權限與稽核。適合更看重權限邊界、多角色交付與合規稽核的團隊；若仍需增量同步，可在 SFTP 准入之下再在「允許的目錄」內使用 rsync over SSH。
實際落地時，很多團隊採用「SFTP 做准入與權限，rsync 做大批量增量同步」的混合方式：SFTP 保證只有授權帳號能存取指定目錄，rsync 在該目錄內負責高效增量傳輸，兼顧安全與效率。
ENOSPC、ECONNREFUSED 等常見同步失敗場景排查與解決
下面給出 5 步排查流程與對應處理思路。
# 1. 確認本機使用的 rsync 路徑（避免與 openrsync 混用）
which rsync
/opt/homebrew/bin/rsync --version
# 2. 測試 SSH 與目標磁碟空間（避免 ENOSPC）
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest" # inode 是否耗盡
# 3. 檢查目標端是否在監聽（避免 ECONNREFUSED）
# 若用 rsync daemon：netstat -an | grep 873
# 若用 rsync over SSH：確保 sshd 正常、防火牆放行 22
# 4. 乾跑一次，看實際傳輸列表
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/
# 5. 正式執行並保留日誌
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log
ENOSPC： 表示目標磁碟或 inode 已滿。清理目標目錄、歸檔舊產物或擴容；必要時在 CI 中增加「同步前檢查磁碟空間」的步驟。
ECONNREFUSED： 表示對端未監聽或防火牆阻斷。若走 SSH，檢查 sshd 與 22 埠；若走 rsync daemon，檢查 873 埠與 rsyncd.conf。
Permission denied / 權限相關： 確認目標目錄屬主與 SSH 使用者一致，以及是否依賴 ACL/--fake-super，若需完整權限保留，優先使用 Homebrew rsync 並查閱其文件。
決策清單：按團隊規模與系統版本選 rsync/openrsync 還是 SFTP 託管
- 僅本機或單節點、Sequoia 自帶 openrsync 即可滿足： 直接使用系統 rsync，腳本中避免依賴 daemon 與複雜 ACL。
- 多節點 CI、需 daemon 或嚴格權限： 統一在各節點安裝 Homebrew rsync，並固定使用其路徑。
- 更看重權限邊界、稽核與多角色交付： 引入 SFTP 閘道 + 目錄隔離，必要時在允許的目錄內再使用 rsync over SSH。
- 希望減少對單機系統與 rsync 版本的依賴： 考慮將「建置產物託管」整體遷到提供 SFTP 的遠端 Mac 託管服務，由服務方保證可用性與權限策略，本機或 CI 只做上傳/下載與校驗。
rsync 與 openrsync 在多數「目錄級增量同步」場景下都能工作，真正決定體驗的是：版本統一、路徑一致、以及故障時的快速排查。當團隊規模擴大、合規與稽核要求提高時，僅靠 rsync 往往不夠，需要清晰的准入層（如 SFTP）和穩定的遠端執行環境。
macOS Sequoia 下為什麼系統自帶的 rsync 換成了 openrsync？
因 GPLv3 許可與蘋果策略衝突，Apple 在 macOS Sequoia 中將傳統 rsync 替換為 BSD 許可的 openrsync。openrsync 體積更小、效能有提升，但在遠端守護模式、ACL 及部分權限同步上與 rsync 3.x 存在差異，遠端建置同步場景需注意相容性。
遠端 Mac 上建置產物同步用 rsync 還是 SFTP 更好？
若團隊已統一使用 rsync 且需增量與校驗，可繼續用 Homebrew 安裝的 rsync 3.x；若更看重權限邊界、稽核與多角色交付，SFTP 閘道配合目錄隔離往往更易管控。兩者可並存：SFTP 做准入與權限，rsync 做大批量增量同步。
同步報 ENOSPC 或 ECONNREFUSED 怎麼排查？
ENOSPC 表示目標磁碟或 inode 已滿，需清理目標或擴容；ECONNREFUSED 表示對端服務未監聽或防火牆阻斷，需檢查 sshd、rsync daemon 或 SFTP 埠是否開放，以及本機與遠端 Mac 的網路與防火牆規則。
在自管 Mac 或 CI 節點上維護 rsync/openrsync 版本與排查網路與磁碟問題，會佔用不少精力。若你更希望把時間用在業務交付上，可考慮將建置產物同步與權限管控交給專業遠端 Mac 託管：SFTPMAC 提供穩定 SFTP 與目錄隔離，相容 rsync over SSH 的增量同步方式，由我們保障節點可用性與權限策略，你只需專注建置與發布。