Linux rsync - mkstemp 失败：权限被拒绝 (13)

rsync - mkstemp failed: Permission denied (13)

提问by

I have the following setup to periodically rsync files from server A to server B. Server B has the rsync daemon running with the following configuration:

我有以下设置来定期将文件从服务器 A 同步到服务器 B。服务器 B 使用以下配置运行 rsync 守护进程：

read only = false
use chroot = false
max connections = 4
syslog facility = local5
log file = /var/adm/rsyncd.log
munge symlinks = false
secrets file = /etc/rsyncd.secrets
numeric ids = false
transfer logging = true
log format = %h %o %f %l %b


[BACKUP]
        path = /path/to/archive
        auth users = someuser

From server A I am issuing the following command:

从服务器 AI 发出以下命令：

rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ [email protected]::BACKUP

BACKUP directory is fully read/write/execute to everyone. When I run the rsync command from server A, I see:

BACKUP 目录对每个人都是完全读/写/执行的。当我从服务器 A 运行 rsync 命令时，我看到：

afile.txt
         989 100%    2.60kB/s    0:00:00 (xfer#78, to-check=0/79)

for each and everyfile in the directory I wish to backup. It fails when I get to writing tmp files:

对于我希望备份的目录中的每个文件。当我开始编写 tmp 文件时它失败了：

rsync: mkstemp "/.afile.txt.PZQvTe" (in BACKUP) failed: Permission denied (13)

Hours of googling later and I still can't resolve what seems to be a very simple permission issue. Advice? Thanks in advance.

经过数小时的谷歌搜索，我仍然无法解决一个看似非常简单的权限问题。建议？提前致谢。

Additional Information

附加信息

I just noticed the following occurs at the beginning of the process:

我刚刚注意到在过程开始时发生了以下情况：

rsync: failed to set permissions on "/." (in BACKUP): Permission denied (13)

Is it trying to set permission on "/"?

它是否试图在“/”上设置权限？

Edit

编辑

I am logged in as the user - someuser. My destination directory has full read/write/execute permission for everyone, including it's contents. In addition, the destination directory is owned by someuser and in someuser's group.

我以用户身份登录 - someuser。我的目标目录对所有人都有完全的读/写/执行权限，包括它的内容。此外，目标目录归某个用户所有并且在某个用户的组中。

Follow up

跟进

I've found using SSH solves this

我发现使用 SSH 解决了这个问题

回答by Mauvis Ledford

Make sure the user you're rsync'd into on the remote machine has write access to the contents of the folder AND the folder itself, as rsync tried to update the modification time on the folder itself.

确保您在远程计算机上 rsync 的用户对文件夹的内容和文件夹本身具有写访问权限，因为 rsync 尝试更新文件夹本身的修改时间。

回答by Jeff Wilbert

Even though you got this working, I recently had a similar encounter and no SO or Google searching was of any help as they all dealt with basic permission issues wheres the solution below is somewhat of an off setting that you wouldn't even think to check in most situations.

即使你得到了这个工作，我最近也遇到了类似的情况，没有 SO 或 Google 搜索有任何帮助，因为它们都处理了基本的权限问题，其中下面的解决方案有点偏离设置，你甚至不会想检查在大多数情况下。

One thing to check for with permission denied that I recently found having issues with rsync myself where permissions were exactly the same on both servers including the owner and group but rsync transfers worked one way on one server but not the other way.

需要检查权限被拒绝的一件事是，我最近发现自己在使用 rsync 时遇到了问题，其中包括所有者和组在内的两台服务器上的权限完全相同，但 rsync 传输在一台服务器上以一种方式工作，但不能以另一种方式工作。

It turned out the server with problems that I was getting permission denied from had SELinux enabled which in turn overrides POSIX permissions on files/folders. So even though the folder in question could have been 777 with root running, the command SELinux was enabled and would in turn overwrite those permissions which produced a "permission denied"-error from rsync.

结果发现服务器有问题，我在启用 SELinux 的情况下被拒绝了权限，这反过来又会覆盖文件/文件夹的 POSIX 权限。因此，即使有问题的文件夹在 root 运行的情况下可能是 777，但启用了 SELinux 命令并反过来覆盖那些从 rsync 产生“权限被拒绝”错误的权限。

You can run the command getenforceto see if SELinux is enabled on the machine.

您可以运行该命令getenforce查看机器上是否启用了 SELinux。

In my situation I ended up just disabling SELINUX completely because it wasn't needed and already disabled on the server that was working fine and just caused problems being enabled. To disable, open /etc/selinux/configand set SELINUX=disabled. To temporarily disable you can run the command setenforce 0which will set SELinux into a permissivestate rather then enforcingstate which causes it to print warnings instead of enforcing.

在我的情况下，我最终只是完全禁用了 SELINUX，因为它不需要并且已经在运行良好的服务器上禁用并且只是导致启用问题。要禁用，请打开/etc/selinux/config并设置SELINUX=disabled。要暂时禁用，您可以运行命令setenforce 0将 SELinux 设置为一个permissive状态，而不是enforcing导致它打印警告而不是强制执行的状态。

回答by Marki555

Rsync daemon by default uses nobody/nogroup for all modules if it is running under root user. So you either need to define params uidand gidto the user you want, or set them to root/root.

如果 Rsync 守护程序在 root 用户下运行，则默认情况下它对所有模块使用 nobody/nogroup。所以你要么需要定义参数uid和gid你想要的用户，要么将它们设置为 root/root。

回答by bolD

I had a similar issue, but in my case it was because storage has only SFTP, without ssh or rsync daemons on it. I could not change anything, bcs this server was provided by my customer.

我有一个类似的问题，但就我而言，这是因为存储只有 SFTP，没有 ssh 或 rsync 守护进程。我无法更改任何内容，因为此服务器是由我的客户提供的。

rsync could not change the date and time for the file, some other utilites (like csync) showed me other errors: "Unable to create temporary file Clock skew detected". If you have access to the storage-server - just install openssh-server or launch rsync as a daemon here.

rsync 无法更改文件的日期和时间，其他一些实用程序（如 csync）向我显示了其他错误：“无法创建临时文件检测到时钟偏差”。如果您有权访问存储服务器 - 只需在此处安装 openssh-server 或启动 rsync 作为守护程序。

In my case - I could not do this and solution was: lftp. lftp's usage for syncronization is below:

就我而言 - 我不能这样做，解决方案是：lftp。lftp 的同步用法如下：

lftp -c "open -u login,password sftp://sft.domain.tld/; mirror -c --verbose=9 -e -R -L /srs/folder /rem/folder"

/src/folder - is the folder on my PC, /rem/folder - is sftp://sft.domain.tld/rem/folder.

/src/folder - 是我电脑上的文件夹，/rem/folder - 是 sftp://sft.domain.tld/rem/folder。

you may find mans by the link lftp.yar.ru/lftp-man.html

你可以通过链接 lftp.yar.ru/lftp-man.html 找到 mans

回答by yuli chika

run in root access ssh chould solve this problem

以 root 访问权限运行 ssh 可以解决这个问题

or chmod 0777 /dir/to/be/backedup/

或者 chmod 0777 /dir/to/be/backedup/

or chown username:user /dir/to/be/backedup/

或者 chown username:user /dir/to/be/backedup/

回答by Shield Edge Technologies

Windows: Check permissions of destination folders. Take ownership if you must to give rights to the account running the rsync service.

Windows：检查目标文件夹的权限。如果您必须为运行 rsync 服务的帐户授予权限，请取得所有权。

回答by Zitrax

This might not suit everyone since it does not preserve the original file permissions but in my case it was not important and it solved the problem for me. rsync has an option --chmod:

这可能不适合所有人，因为它不保留原始文件权限，但在我的情况下它并不重要，它为我解决了问题。rsync 有一个选项--chmod：

--chmodThis option tells rsync to apply one or more comma-separated lqchmodrq strings to the permission of the files in the transfer. The resulting value is treated as though it was the permissions that the sending side supplied for the file, which means that this option can seem to have no effect on existing files if --perms is not enabled.

--chmod此选项告诉 rsync 将一个或多个逗号分隔的 lqchmodrq 字符串应用于传输中文件的权限。结果值被视为发送方为文件提供的权限，这意味着如果 --perms 未启用，此选项似乎对现有文件没有影响。

This forces the permissions to be what you want on all files/directories. For example:

这会强制所有文件/目录的权限都是您想要的。例如：

rsync -av --chmod=Du+rwx SRC DST

would add Read, Write and Execute for the user to all transferred directories.

将为用户添加读取、写入和执行到所有传输的目录。

回答by Wolf

I imagine a common error not currently mentioned above is trying to write to a mount space (e.g., /media/drivename) when the partition isn't mounted. That will produce this error as well.

我想目前上面没有提到的一个常见错误是/media/drivename在分区未安装时尝试写入安装空间（例如，）。这也会产生这个错误。

If it's an encrypted drive set to auto-mount but doesn't, might be an issue of auto-unlocking the encrypted partition before attempting to write to the space where it is supposed to be mounted.

如果它是一个设置为自动挂载但没有设置为自动挂载的加密驱动器，则可能是在尝试写入应该挂载的空间之前自动解锁加密分区的问题。

回答by chingis

I had the same error while syncing files inside of a Docker container and the destination was a mounted volume (Docker for mac), I run rsyncvia su-exec <user>. I was able to resolve it by running rsyncas rootwith -ogflags (keep owner and group for destination files).

我在 Docker 容器内同步文件时遇到了同样的错误，目标是一个挂载的卷（Docker for mac），我rsync通过su-exec <user>. 我可以通过运行来解决它rsync作为root与-og标志（保持所有者和组为目标文件）。

I'm still not sure what caused that issue, the destination permissions were OK (I run chown -R <user>for destination dir before rsync), perhaps somehow related to Docker for Mac slow filesystem.

我仍然不确定是什么导致了这个问题，目标权限没问题（我chown -R <user>之前为目标目录运行rsync），也许与 Mac 慢速文件系统的 Docker 有某种关系。

回答by hao

I encountered the same problem and solved it by chownthe user of the destination folder. The current user does not have the permission to read, write and execute the destination folder files. Try adding the permission by chmod a+rwx <folder/file name>.

我遇到了同样的问题，并由chown目标文件夹的用户解决了。当前用户无权读取、写入和执行目标文件夹文件。尝试通过添加权限chmod a+rwx <folder/file name>。