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

发布于 2024-07-14 23:36:32 字数 330 浏览 12 评论 0 原文

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

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

I'm getting a confusing error from rsync and the initial things I'm finding from web searches (as well as all the usual chmod'ing) are not solving it:

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]

It seems to be working despite that error, but it would be nice to get rid of that.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(13

当梦初醒 2024-07-21 23:36:32

如果 /foo/bar 位于 NFS(或者可能是某些 FUSE 文件系统)上,则可能是问题所在。

无论哪种方式,将 -O / --omit-dir-times 添加到命令行将避免它尝试在目录上设置修改时间。

If /foo/bar is on NFS (or possibly some FUSE filesystem), that might be the problem.

Either way, adding -O / --omit-dir-times to your command line will avoid it trying to set modification times on directories.

じее 2024-07-21 23:36:32

该问题可能是由于 /foo/bar 不属于远程 darwin (OS X) 系统上的写入进程所致。
解决该问题的方法是在远程站点上设置足够的所有者。

由于此答案已被投票,因此希望对某人有用,我将对其进行扩展以使其更清晰。

发生这种情况的原因是 rsync 可能在复制文件时尝试设置任意修改时间(mtime)。

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

The issue is probably due to /foo/bar not being owned by the writing process on a remote darwin (OS X) system.
A solution to the issue is to set adequate owner on the remote site.

Since this answer has been voted, and therefore has been hopefully useful to someone, I'm extending it to make it clearer.

The reason why this happens is that rsync is probably trying to set an arbitrary modification time (mtime) when copying files.

In order to do this darwin's system utime() function requires that the writing process effective uid is either the same as the file uid or super user's one, see opengroup utime's page.
Check this discussion on rsync mailing list as reference.

迷爱 2024-07-21 23:36:32

正如 @racl101 评论了一个答案,这个问题可能与文件夹所有者有关。 rsync 命令应由与文件夹所有者相同的用户执行。 如果不一样,可以更改。

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

As @racl101 has commented on an answer, this problem might be related to the folder owner. The rsync command should be done by the same user as the folder owner's one. If it's not the same, you can change it.

chown -R userCorrect /remote/path/to/foo/bar
若相惜即相离 2024-07-21 23:36:32

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

I had the same problem. For me the solution is to delete the remote file and let rsync create again.

抱着落日 2024-07-21 23:36:32

我的问题是“接收器安装点”安装不正确。 它处于只读模式(出于某种奇怪的原因)。
看起来 rsync 正在复制文件,但事实并非如此。
我检查了 fstab 文件并将挂载选项更改为默认值,重新挂载文件系统并再次执行 rsync。 那么一切都好。

The problem in my case was that the "receiver mountpoint" was incorrectly mounted. It was in read-only mode (for some extrange reason).
It looked like rsync was copying the files, but it was not.
I checked my fstab file and changed mount options to default, re-mount file system and execute rsync again. All fine then.

心作怪 2024-07-21 23:36:32

当我写入一个不能(正确)处理时间的文件系统时,我已经看到了这个问题——我认为是 SMB 共享或 FAT 之类的。

你的目标文件系统是什么?

I've seen that problem when I'm writing to a filesystem which doesn't (properly) handle times -- I think SMB shares or FAT or something.

What is your target filesystem?

全部不再 2024-07-21 23:36:32

这发生在我的 xfs (rw,relatime,seclabel,attr2,inode64,noquota) 类型的分区上,其中目录由我们都是成员的组中的另一个用户拥有。 组成员身份在登录前就已建立,并且整个目录结构是组可写的。 我已手动运行 sudo chown -R otheruser.groupdirectory 和 sudo chmod -R g+rwdirectory 来确认这一点。

我仍然不知道为什么它最初不起作用,但通过 sudo chown -R myuser.group directory 获取所有权修复了它。 也许与 SELinux 有关?

This happened to me on a partition of type xfs (rw,relatime,seclabel,attr2,inode64,noquota), where the directories where owned by another user in a group we were both members of. The group membership was already established before login, and the whole directory structure was group-writeable. I had manually run sudo chown -R otheruser.group directory and sudo chmod -R g+rw directory to confirm this.

I still have no idea why it didn't work originally, but taking ownership with sudo chown -R myuser.group directory fixed it. Perhaps SELinux-related?

偏闹i 2024-07-21 23:36:32

我也遇到了这个问题,我遇到的问题是包含我试图发送的文件的根文件夹的权限问题。 我不关心 rsync 中包含的根文件夹,我只关心其中的内容。 该错误来自我的命令,我需要在末尾指定一个额外的 / 。 如果您没有尾部斜杠,rsync 将尝试设置文件夹时间。

示例:

这将尝试在 html 上设置时间

rsync /var/www/html/ [email protected]:html

这不会

rsync /var/www/html/ [email protected]:html/

I came across this problem as well and the issue I was having was a permissions issue with the root folder that contained the files I was trying to send over. I don't care about that root folder being included with rsync I just care what's in it. The error was coming from my command where I need to specify an additional / at the end. If you do not have that trailing slash rsync will attempt to set times the folder.

Example:

This will attempt to set times on html

rsync /var/www/html/ [email protected]:html

This will not

rsync /var/www/html/ [email protected]:html/
罗罗贝儿 2024-07-21 23:36:32

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

This error might also pop-up if you run the rsync process for files that are not recently modified in the source or destination...because it cant set the time for the recently modified files.

情定在深秋 2024-07-21 23:36:32

在迁移助手决定将所有时间戳设置为复制操作发生的时间(而不是原始文件的时间)后,我在尝试修复新 MacOS Monterey 上的时间戳时遇到了此错误。

anddam 的回答对我没有帮助,因为 rsync 命令中使用的远程用户确实与目录和文件的所有者。

经过进一步研究,我意识到我无法通过 SSH 访问 Mac 的 Documents 目录(错误 ls: Documents: 不允许操作)。

我通过在 Mac 上打开“系统偏好设置”,然后选择“安全和安全”来解决该问题。 隐私,转到隐私选项卡,选择完全磁盘访问并选中sshd-keygen-wrapper旁边的框。

I ran into this error trying to fix timestamps on a new MacOS Monterey, after the Migration Assistant decided to set all of them to the time the copy operation occurred, instead of the original file's.

anddam's answer did not help me, as the remote user used in the rsync command did match the directories and files owner.

After further research, I realised that I had no access to the Mac's Documents directory over SSH (error ls: Documents: Operation not permitted).

I managed to fix the problem by opening System Preferences on the Mac, then selecting Security & Privacy, go to Privacy tab select Full Disk Access and check the box next to sshd-keygen-wrapper.

我不是你的备胎 2024-07-21 23:36:32

文件路径:Pods-> 目标支持文件 -> Pod- -> Pods--frameworks

替换以下行:

source="$(readlink "${source}")"

to

source="$(readlink -f "${source}")"

注意:如果无法找到该文件,则执行 Xcode Search "source="$(readlink "${source}")""

File path: Pods -> Targets Support Files -> Pods-<PROJECT_NAME> -> Pods-<PROJECT_NAME>-frameworks

Replace the below line:

source="$(readlink "${source}")"

to

source="$(readlink -f "${source}")"

Note: If not able to find the file then do Xcode Search "source="$(readlink "${source}")""

耳根太软 2024-07-21 23:36:32

我在使用lsyncd同步两个NAS(阿里云NAS)时也遇到了这个问题。

用户无法将源NAS同步到目标NAS根目录,因为根目录权限无法修改,用户只能将数据同步到子目录。

当同步数据到子目录时,用户可以使用 chmod & chown 更改子目录模式或所有者。

之前

# /etc/lsyncd.conf
source = "/app/data/nas1",
target = "/app/data/nas2"

之后

# /etc/lsyncd.conf
source = "/app/data/nas1"
target = "/app/data/nas2/subDirectory"

I also met this problem when I use lsyncd to sync two NAS(AlibabaCloud NAS).

User can't sync source NAS to dst NAS root directory because the root directory permission can not be modified, user can only sync data to sub-directory.

when sync data to sub-directory, user can use chmod & chown to change sub-directory mode or owner.

Before

# /etc/lsyncd.conf
source = "/app/data/nas1",
target = "/app/data/nas2"

After

# /etc/lsyncd.conf
source = "/app/data/nas1"
target = "/app/data/nas2/subDirectory"
心奴独伤 2024-07-21 23:36:32

可能是您没有某些文件的权限。 从管理员帐户中,尝试“sudo rsync -av ”。或者,启用 root 帐户并以 root 身份登录。 这应该可以让你彻底冲洗你的系统并暴力破解你的 rsync! ;-) 我不确定上面提到的 --extended-attributes 是否有帮助,但我也把它放进去,只是为了更好的衡量。

It could be that you don't have privileges to some of the files. From an administrator account, try "sudo rsync -av " Alternately, enable the root account and sign in as root. That should allow you to completely hose your system and brute force your rsync! ;-) I'm not sure if the above mentioned --extended-attributes will help, but I threw it in too, just for good measure.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文