我使用 rsync 将文件发送到远程服务器，主要使用有限带宽连接，也可能出现数据包丢失或抖动，有时 rsync 会随机失败并出现以下错误：
default_perms_for_dir: sys_acl_get_file(photos/2019-05-11_01-31-51, ACL_TYPE_DEFAULT): No such file or directory, falling back on umask
rsync: mkstemp "/photos/2019-05-11_01-31-51/.data.txt.CJXeor" (in remote_bkp_site) failed: No such file or directory (2)
rsync: mkstemp "/photos/2019-05-11_01-31-51/.output_20190511-013202.mp4.Bhka2P" (in remote_bkp_site) failed: No such file or directory (2)
如果我再次运行 rsync，它将正常工作并成功将所有必要的文件发送到远程站点。此错误随机发生，不在同一文件上。
我在服务器端使用 rsyncd 守护程序，我的根目录可能有大约 1000 个文件。旧文件没有变化，我主要使用 rsync 将新文件推送到服务器。
我做了很多研究，发现这个错误大多发生在挂载（CIFS）或权限错误上，但我的情况不是这样。此外，如果我再次运行 rsync 几次，它最终会同步所有文件。
我相信这个错误与我通过带宽有限的 4G 宽带连接同步服务器有关，并且可能会发生数据包丢失。
有人有什么建议或遇到过类似的情况吗？
答案1
我发现在 Linux 下，跨不同 fs 类型传输文件时，mkstemp 调用可能会失败，因为源系统上的有效名称在目标系统上无效。
这意味着即使只触摸文件名也会失败，并且并非所有 fs 似乎都接受转义序列以避免这种情况。我验证我可以触摸目标文件夹，但当我合并第一个无效字符（例如“：”）时，即使转义，它也会失败。
答案2
原因
Rsync 似乎找不到它应该同步的某些文件。当您在 rsync 运行时在源中添加和/或删除文件时，就会发生这种情况。
可能的原因是 rsync 在同步开始时对源进行了初始扫描，当 rsync 最终将文件同步到目标时，一些文件已经消失了。然后它会抛出一个错误。
这也解释了为什么经过几次尝试后，同步会成功（因为初始扫描和复制文件数据之间的时间变短，因此文件在扫描和复制之间发生变化的可能性更小）。
失败的文件看起来像是临时文件。这可能表明它们未同步到目标并不是真正的问题。
解决方案
解决方案是防止源在同步过程中发生变化，例如通过从数据的静态（快照）副本进行同步。您也许还可以学会忍受错误。
答案3
我也遇到了同样的情况。问题是我在后台同时运行多个 rsync 进程，同时使用了删除源文件的选项。
已解决killall rsync。然后最后一次运行脚本，一切正常。