rsync 無法遠端使用 Linux Mint 20
我使用
rsync了多年，從未遇到過這麼奇怪的問題：一切正常，除非遠端機器執行 Linux Mint 20（嘗試使用其中 2 個，一個仍在執行 20.1，另一個是全新安裝20.2)。無論是單個文件、整個目錄還是僅列出資源：rsync協商後立即掛起（無論我是“推”還是“拉”）。如果遙控器是 Debian、Armbian，甚至是 Mint 18（我剛剛打開一台舊筆記型電腦進行檢查），同樣的命令也可以正常工作。即使是簡單的事情rsync remote:/path/to/file .掛起。我已經嘗試了可用的調試選項，並且發現一切都順利進行了身份驗證（通過 SSH 密鑰或密碼）。如果我提供了錯誤的密碼，我會得到正確的“退出”。但是，如果我提供了正確的密碼/密鑰，則在身份驗證後會話會立即掛起，而不會提供更多線索。我看到的最後一件事是
exec request accepted。在遠端機器上使用表明已經產生ps了相應的程序（是的，在你問之前：通過 SSH 連接到機器工作正常，甚至按預期工作 - 只是沒有）。rsync``scp``rsync作為最後的手段和解決方法，我
rsyncd在遠端機器上啟動了一個臨時的：rsync --config=/tmp/rsyncd.conf --daemon --no-detach然後用
rsync remote::share/path/to/file. 雖然這有效並且我完成了目前任務，但我不想在每次需要同步某些內容時重複。編輯：
有人可能會假設遠端的一些輸出
.bashrc可能會干預：（ssh remotehost /bin/true > out.dat正如手冊頁建議檢查的那樣）導致一個零字節文件，所以這不應該是原因。
strace對 3 個遠端生成的rsync程序（順便說一句，它們都有相同的命令行，一個帶前導，兩個不帶前導bash）顯示其中 2 個以 . 結尾wait4(-1,，另一個以{tv_sec=32, tv_usec=23154}. 正如預期的那樣， “客戶端”（rsync由使用者呼叫）也顯示一個wait4(-1,，因為它很可能等待遠端端響應。**任何想法可能是罪魁禍首，如何解決問題，**甚至如何進一步縮小範圍？至於調試，我已經使用過
rsync --debug=all4 -avve "ssh -vvv" …，這就是我所描述的。作為參考，
rsyncd.conf上述解決方法中使用的方法：使用 chroot = true 主機允許 = 192.168.0.0/24 傳輸記錄 = true 日誌文件 = /tmp/rsyncd.log 日誌格式 = %h %o %f %l %b [分享] 評論 = 分享 路徑 = /mnt/share 只讀 = 沒有 清單 = 是的 uid = 沒有人 gid = 無組
我找到了罪魁禍首——在我無法用第三台 Mint20 機器重現問題之後。事實證明，只有在其中一台 Mint20 機器作為“伺服器”涉及時才會發生這種情況，從而縮小了搜尋範圍。跑到
which rsync那裡並得到了/usr/local/bin/rsync支持。這（連同“伺服器”端顯示的第 4 個 rsync 程序，我認為它屬於我經常執行的其他一些操作而忽略了它）讓我走上了正軌：
/usr/local/bin/rsync被放置以解決自 2006 年以來已知的rsync 錯誤（並且仍未修復；在此處找到腳本）。雖然它多年來很好地解決了這個令人討厭的問題，因為該機器僅用作客戶端，但現在需要更換機器，並且為了轉移，它充當伺服器，它適得其反。為了解決目前問題的原始問題，我將腳本移動到僅在
PATH活動使用者的目錄中，但不是root（遠端rsync總是由 root 生成，並且應該得到原始的/usr/bin/rsync）。經過各個方向的測試，似乎有效（只需要等待我應用原始解決方法的“那個 cron 工作”）。PS：對於那些也使用該
rsync-no-vanished腳本的人，稍作調整即可解決。只需將腳本更改為：if [[ $(id -u) -eq 0 ]]; then /usr/bin/rsync $@ else # original "rsync-no-vanished" script in here fi這樣，當由 root 呼叫時（例如生成的遙控器），它只是引用原始
rsync二進製文件，並且只使用“解決方法”進行客戶端呼叫。**PS：**在聯繫項目提供細節和建議修復後，腳本很快更新，因此以後避免了類似的情況（感謝韋恩的及時回复！）。