rsync错误：无法在“ / foo / bar”上设置时间：不允许操作

194

我从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]

尽管存在该错误，它似乎仍在工作，但是摆脱它会很好。

rsync file-transfer

— 德雷夫斯
source

不，据我所知只是一个普通目录。

— dreeves

刚刚遇到了类似的问题，尽管我的错误代码是22：rsync：无法设置时间...无效参数（22）。经过一番检查后，发现我的文件的日期为1956年最后一次修改！解决方案：触摸所有文件，问题解决。:)“查找。

— print0

我发现，如果您还已将cron作业设置到相同的目的地，则会显示此错误。更改cron作业（crontab）的时间将有助于解决该问题。就我而言，如果我还设置了cron作业，则只有执行手动rysnc时，才会出现此错误。

— NelsonGon

286

如果/foo/bar在NFS（或可能是某些FUSE文件系统）上，则可能是问题所在。

无论哪种方式，在命令行中添加-O/ --omit-dir-times都可以避免尝试在目录上设置修改时间。

— 乔恩·布莱特
source

8

有趣的是，我正在将ext3同步到ext3，两个操作系统都是linux。我以前从未使用过此开关。-O做到了，但我希望我不必使用它。

— d -_- b 2010年

3

谢谢！事实证明，某些VPS主机（例如xlshosting.nl）在内部使用此功能，这可能会使rsync出现问题。

— Frederik 2012年

2

从Linux ext4到Linux ext4同步时，我遇到了同样的问题：符号链接（不是目录）的“无法设置时间：不允许操作” 。 -O显然没有帮助。当我的备份分区是ext3而不是ext4时，就不会发生这种情况。

— Marius Gedminas

10

我正在使用rsync -avc，添加-O没有帮助。然后，我读到-a是-rlptgoD的等价物，其中包括-t，我猜想它覆盖了-O。因此，对我来说，解决方法是使用-rlpgoDvc

— dlink

3

您可以添加@dlink --no-t以删除隐含选项。

— Noam Nelke，

86

问题可能是由于/ foo / bar不属于远程darwin（OS X）系统上的写入过程所拥有。 解决此问题的方法是在远程站点上设置适当的所有者。

由于此答案已被投票通过，因此有望对某人有用，因此，我将其扩展以使其更加清晰。

发生这种情况的原因是，rsync可能试图在复制文件时设置一个任意的修改时间（mtime）。

为了做到这一点，darwin的系统utime()功能要求写入过程有效的uid与文件uid或超级用户的uid相同，请参见opengroup utime的页面。查看有关rsync邮件列表的讨论，以作为参考。

— 安达姆
source

10

在Linux上也一样（在我的情况下为Debian Squeeze）...如果我不是目标目录的所有者，则rsync会显示“设置时间失败”错误消息。（仅在目录上具有写许可权还不够。）

— ddekany

1

我陷入了同样的问题。直到使用uid = user挂载NTFS。

— Givenkoa 2012年

3

当我使用与本地本地Bash脚本中尝试通过rsync登录的用户相同的用户，使用rsync命令更改了要影响的目录的所有者（在远程服务器上）时，此错误对我来说消失了。换句话说：我正在尝试/remote/path/to/foo/bar使用以下命令在远程服务器上进行写入：rsync -avzP --exclude '.DS_Store' /local/path/to/foo/bar/ user1@1.2.3.4:/remote/path/to/foo/bar 并得到了以下错误消息，该错误消息在我成为这样user1的所有者时消失了/remoe/path/to/foo/bar：$ chown -R user1 /remote/path/to/foo/bar

— racl101 2015年

1

例如，如果您与组中的其他用户共享文件，则使用粘性位，那么更改所有者并不是真正的解决方案。我们不使用-t并添加-O来防止此警告。

— R. van Twisk

1

您可以扩展答案以详细说明用户是否属于拥有文件/目录的组吗（如果这样做）或不起作用？

— 伊利亚·林恩

4

由于@ racl101对答案进行了评论，因此此问题可能与文件夹所有者有关。rsync命令应该由文件夹所有者的同一用户执行。如果不同，则可以更改。

chown -R userCorrect /remote/path/to/foo/bar

— 鲁德·阿克尔
source

2

在我的情况下，问题是“接收器安装点”未正确安装。它处于只读模式（出于某些扩展原因）。看起来rsync正在复制文件，但事实并非如此。我检查了fstab文件，并将挂载选项更改为默认选项，重新挂载文件系统并再次执行rsync。一切都很好。

— 里帕
source

2

我有同样的问题。对我来说，解决方案是删除远程文件，然后rsync再次创建。

— 蛇怪
source

0

当我写一个不（正确）处理时间的文件系统时，我已经看到了这个问题-我认为SMB共享或FAT或其他东西。

您的目标文件系统是什么？

— 大卫·沃尔沃
source

我在Mac电脑上，正在与Linux（一台slicehost机器）同步。

— dreeves

啊，很奇怪...但是，由于您在Mac上使用rsync，因此我应该警告您：它没有正确保留所有OS X文件属性，因此可能发生“坏事”。参见例如：blog.plasticsfuture.org/2006/04/23/mac-backup-software-harm

— David Wolever

但是，您可以使用MacPorts（sudo port install rsync）的最新版本，它的发行量将减少。要检查它：：rsync --versionrsync版本3.0.5协议版本30 ...附加，ACL，xattrs，iconv，symtimes，文件标志...（ACL和xattrs是重要的）

— David Wolever 09年

1

在Macintosh上，rsync确实确实设置了所有文件属性，并且已经设置了相当长的时间，请注意，引用“可能发生不良事件”的URL的日期为2006年！

— tgunr

2

答案确实不应该包含问题。这将更适合作为评论。

— 布莱恩

0

可能是您没有某些文件的特权。从管理员帐户，尝试“ sudo rsync -av”，或者，启用root帐户并以root用户身份登录。那应该使您完全掌握系统并强行使用rsync！;-)我不确定上述--extended-attributes是否会有所帮助，但我也把它放在了很好的范围内。

— 队长
source

0

这发生在类型为的分区上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有关？

— 山姆·布莱曼
source

手册页上显示了应用程序的UID。必须匹配文件的UID utime()才能正常工作。您也可以以root身份运行并执行。但是，如果文件的UID不同，则不允许您将时间更改为“现在”以外的任何时间。

— Alexis Wilke

您可以链接到这样的手册页吗？我的都没提utime()。

— 山姆·布莱曼

1

linux.die.net/man/2/utime相关段落：“在以下情况下允许更改时间戳：进程具有适当的特权，或者有效的用户ID等于文件的用户ID，或者时间为NULL，并且进程具有文件的写权限。”

— Alexis Wilke

0

如果您对源或目标中最近未修改的文件运行rsync进程，也可能会弹出此错误...因为它无法设置最近修改的文件的时间。

— 古迪普·辛格
source