我从rsync中得到一个令人困惑的错误，我从网络搜索中找到的最初的东西（以及所有通常的chmod'ing）都没有解决它：
rsync: failed to set times on "/foo/bar": Operation not permitted (1)
rsync error: some files could not be transferred (code 23)
at /SourceCache/rsync/rsync-35.2/rsync/main.c(992) [sender=2.6.9]
尽管有这样的错误，它似乎仍在工作，但摆脱它会很好。
如果/foo/bar在NFS（或可能是某些FUSE文件系统）上，那可能就是问题所在。
无论哪种方式，将-O / --omit-dir-times添加到您的命令行将避免它尝试在目录上设置修改时间。
问题可能是由于/ foo / bar不属于远程darwin（OS X）系统上的写入过程。该问题的解决方案是在远程站点上设置足够的所有者。
由于这个答案已经被投票，因此对某人有用，我正在扩展它以使其更清楚。
发生这种情况的原因是rsync可能在复制文件时尝试设置任意修改时间（mtime）。
为了做到这一点，darwin的系统utime（）函数要求写入过程有效uid与文件uid或超级用户的相同，请参阅opengroup utime's page。检查rsync邮件列表上的this discussion作为参考。
在我的情况下的问题是“接收器安装点”被错误地安装。它处于只读模式（出于一些额外的原因）。看起来rsync正在复制文件，但事实并非如此。我检查了我的fstab文件并将挂载选项更改为默认值，重新挂载文件系统并再次执行rsync。一切都很好。
我有同样的问题。对我来说，解决方案是删除远程文件，让rsync再次创建。
当我写一个没有（正确）处理时间的文件系统时，我已经看到了这个问题 - 我认为SMB共享或FAT等等。
你的目标文件系统是什么？
可能是您没有某些文件的权限。从管理员帐户，尝试“sudo rsync -av”或者，启用root帐户并以root用户身份登录。这应该允许你完全软管你的系统和暴力强制你的rsync！ ;-)我不确定上面提到的--extended-attributes是否有帮助，但我也把它扔了，只是为了好的措施。
这发生在我的xfs (rw,relatime,seclabel,attr2,inode64,noquota)类型的分区上，其中我们都是其成员的组中的另一个用户所拥有的目录。在登录之前已经建立了组成员资格，整个目录结构是可写组的。我手动运行sudo chown -R otheruser.group directory和sudo chmod -R g+rw directory来证实这一点。
我仍然不知道为什么它最初不起作用，但取得所有权与sudo chown -R myuser.group directory修复它。也许与SELinux有关？
如果您对源或目标中最近未修改的文件运行rsync进程，则可能还会弹出此错误...因为它无法为最近修改的文件设置时间。