【问题标题】:rsync - mkstemp failed: Permission denied (13) [closed]rsync - mkstemp 失败:权限被拒绝(13)[关闭]
【发布时间】:2012-06-17 20:49:19
【问题描述】:

我有以下设置来定期将文件从服务器 A rsync 到服务器 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

我从服务器 A 发出以下命令:

rsync -adzPvO --delete --password-file=/path/to/pwd/file/pwd.dat /dir/to/be/backedup/ someuser@192.168.100.100::BACKUP

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

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

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

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

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

其他信息

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

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

是否尝试在“/”上设置权限?

编辑

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

跟进

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

【问题讨论】:

  • 此配置是否曾经工作过一次?
  • @sputnick:我使用相同的配置通过 rsync 进行 PULL,但这个过程是 PUSH。所以为了回答你的问题,我没有在这种设置中使用过这个配置。
  • 使用 SSH 是一种解决方法,并不是真正的解决方案或理解这里的权限问题。我遇到了类似的问题,使用 SSH 对我来说不是一个选项:/
  • 错误 (13) 是文件夹权限问题。这在这里很好地解释了superuser.com/questions/398146/…

标签: linux permissions rsync


【解决方案1】:

目标目录和子目录的组用户名应与每个用户相同。

如果用户是'abc',那么目标目录应该是 lrwxrwxrwx 1 abc abc 34 Jul 18 14:05 Destination_directory

命令 chown abc:abc Destination_directory

【讨论】:

    【解决方案2】:

    如果您使用的是 Raspberry pi 或其他带有 sudo 的 Unix 系统,您需要告诉远程机器 rsync 和 sudo 程序所在的位置。

    为了安全起见,我输入了完整的路径。

    这是我的例子:

    rsync --stats -paogtrh --progress --omit-dir-times --delete --rsync-path='/usr/bin/sudo /usr/bin/rsync'  /mnt/drive0/ pi@192.168.10.238:/mnt/drive0/
    

    【讨论】:

      【解决方案3】:

      我遇到了同样的问题,所以我首先通过 SSH 连接到服务器,以确认我能够使用以下命令登录到服务器:

      ssh -i /Users/Desktop/mypemfile.pem user@ec2.compute-1.amazonaws.com
      

      然后在新建终端

      我使用 SCP 将一个小文件复制到服务器,以确保我能够建立连接:

      scp -i /Users/Desktop/mypemfile.pem /Users/Desktop/test.file user@ec2.compute-1.amazonaws.com:/home/user/test/
      

      然后在同一个新终端中,我尝试运行 rsync:

      rsync -avz -e "ssh -i /Users/Desktop/mypemfile.pem" /Users/Desktop/backup/image.img.gz user@ec2.compute-1.amazonaws.com:
      

      【讨论】:

        【解决方案4】:

        还有另一种获得此症状的方法:我正在通过 ssh 从远程机器同步到具有 NTFS-3G (FUSE) 文件系统的 Linux 机器。最初文件系统是在引导时挂载的,因此归根用户所有,当我从远程机器执行 rsync 推送时,我收到了这个错误消息。然后,作为推送 rsync 的用户,我做了:

        $ sudo umount /shared
        $ mount /shared
        

        错误消息消失了。

        【讨论】:

          【解决方案5】:

          令人惊讶的是,没有人提到所有强大的 SUDO。 遇到了同样的问题,sudo 修复了它

          【讨论】:

          • "sudo" 不是解决方法,除非您确定问题出在哪里。通常情况下,盲目的 sudo 会导致比它解决的问题更多的问题。
          【解决方案6】:

          我有带有 rsyncd 的 Centos 7 服务器: /etc/rsyncd.conf

          [files]
          path = /files
          

          默认情况下 selinux 会阻止 rsyncd 访问 /files 文件夹

          # this sets needed context to my /files folder
          sudo semanage fcontext -a -t rsync_data_t '/files(/.*)?'
          sudo restorecon -Rv '/files'
          # sets needed booleans
          sudo setsebool -P rsync_client 1
          

          禁用 selinux 是一个简单但不是好的解决方案

          【讨论】:

          • 非常感谢,您终于解除了我安装 rsync 的阻碍!我完全同意你的观点,SELinux 的存在是有原因的,可惜很多人只是禁用它而不是学习它的工作原理。
          【解决方案7】:

          注意下一个示例中的 -e ssh 和 jenkins@localhost::

          rsync -r  -e ssh --chown=jenkins:admin --exclude .git --exclude Jenkinsfile --delete ./ jenkins@localhost:/home/admin/web/xxx/public
          

          这对我有帮助

          P.S. 今天,我意识到当您将 jenkins 用户更改(添加)到某个组时,从属(代理)重新启动后将应用权限。而我的解决方案(-e ssh 和 jenkins@localhost:)仅在您无法重新启动代理/服务器时才需要。

          【讨论】:

            【解决方案8】:

            我在 CentOS 7 的情况下遇到了同样的问题。我浏览了很多文章、论坛但找不到解决方案。 问题出在 SElinux 上。在服务器端禁用 SElinux 有效。 检查服务器端的 SELinux 状态(使用 rysnc 从中提取数据) 检查 SELinux 状态并禁用它的命令

            $getenforce

            Enforcing ## 这意味着 SElinux 已启用

            $setenforce 0

            $getenforce

            允许

            现在尝试在客户端运行 rsync 命令,它对我有用。 万事如意!

            【讨论】:

              【解决方案9】:

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

              【讨论】:

              • 最好也写例子。
              • 拥有整个路径层次结构显然很重要。作为目标文件夹的所有者是不够的。您也必须拥有父目录。我有点惊讶,但只有当我是所有父母的主人时它才会起作用......
              【解决方案10】:

              我在 Docker 容器内同步文件时遇到了同样的错误,并且目标是已安装的卷(Docker for mac),我通过 su-exec <user> 运行 rsync。我可以通过使用-og 标志运行rsync 作为root 来解决它(保留目标文件的所有者和组)。

              我仍然不确定导致该问题的原因,目标权限正常(我在rsync 之前为目标目录运行chown -R <user>),可能与Docker for Mac 慢速文件系统有关。

              【讨论】:

                【解决方案11】:

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

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

                【讨论】:

                  【解决方案12】:

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

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

                  这会强制将所有文件/目录的权限设置为您想要的。例如:

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

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

                  【讨论】:

                  • 使用 rsync over SSH 将 Synology NAS 备份到远程服务器也是如此。
                  • Synology-NAS:我必须将 --rsync-path=/bin/rsync 添加到 rsync 以摆脱“权限被拒绝”。
                  • 正如@fdelia 建议将--rsync-path=/usr/bin/rsync 添加到rsync 命令中,我现在拥有rsync -rvp --rsync-path=/usr/bin/rsync $SOURCE $DESTINATION 神奇地解决了我的问题。但我不知道为什么,这有点令人沮丧。
                  【解决方案13】:

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

                  【讨论】:

                    【解决方案14】:

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

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

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

                    【讨论】:

                      【解决方案15】:

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

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

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

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

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

                      【讨论】:

                      • 对我来说就是 SELinux!谢谢!
                      • 如果我得到 getenforce 的“command not found”,这是否意味着我的服务器没有 SELinux?
                      • @Marecky 不一定,这取决于您运行命令的方式和/或 $PATH 变量的设置方式可能导致找不到命令。尝试运行/usr/sbin/getenforce,这是getenforce 通常所在的完整路径。
                      • @Marecky 您还可以根据发行版搜索已安装的软件包 yum list installed | grep selinux 或 apt list --installed | grep selinux。请注意,如果发现 libselinux 并不意味着它在服务器上已启用和/或处于活动状态。要检查的 selinux 的另一种替代方法是 AppArmor apparmor_status。
                      【解决方案16】:

                      我遇到了类似的问题,但在我的情况下,这是因为存储只有 SFTP,没有 ssh 或 rsync 守护程序。我无法更改任何内容,因为此服务器是我的客户提供的。

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

                      就我而言 - 我无法做到这一点,解决方案是: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 - 是我电脑上的文件夹,/rem/folder - 是 sftp://sft.domain.tld/rem/folder。

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

                      【讨论】:

                      • 天才!感谢您提供这么棒的工具!
                      【解决方案17】:

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

                      【讨论】:

                      • 这个答案对我很有帮助。我不得不设置 rsync 守护进程,因为 rsync over ssh 太慢了(另外我必须允许 root over ssh,这不好)。但即使远程守护进程已经以 root 身份运行,我仍然收到failed to set times on "/." (in linuxbackup): Operation not permitted (1)。在rsyncd.conf 中将uid 和gid 更改为root 修复了该问题
                      【解决方案18】:

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

                      【讨论】:

                      • 感谢您的回复。我已确保我是具有权限、所有权和组设置的同一用户。请查看我的编辑。
                      • 谢谢。我在 Synology DiskStation 上遇到了这个问题,它解决了这个问题。所有者是否为管理员无关紧要,该文件夹必须由 rsync 作业用户拥有。
                      猜你喜欢
                      • 2014-11-04
                      • 1970-01-01
                      • 2015-05-03
                      • 1970-01-01
                      • 1970-01-01
                      • 2012-09-04
                      • 1970-01-01
                      • 2021-04-02
                      • 2014-03-24
                      相关资源
                      最近更新 更多