Rsync - mkstemp не удалось: разрешение отклонено (13)

Ответ 1

Удостоверьтесь, что пользователь, которого вы подключили к удаленному компьютеру, имеет доступ на запись к содержимому папки И самой папки, поскольку rsync попытался обновить время модификации самой папки.

Ответ 2

Несмотря на то, что у вас это работает, у меня недавно была аналогичная встреча, и ни один SO или поиск в Google не помогли, поскольку все они касались вопросов с базовыми разрешениями. Ниже приведенное решение представляет собой некую настройку, в которой вы даже не подумайте, чтобы проверить в большинстве ситуаций.

Одна вещь, которую нужно проверить с разрешения, отрицала, что я недавно обнаружил, что у меня проблемы с самим rsync, где разрешения на обоих серверах были одинаковыми, включая владельца и группу, но передача rsync работала одним способом на одном сервере, но не с другим.

Оказалось, что сервер с проблемами, с которыми мне было отказано в доступе, был включен SELinux, который, в свою очередь, переопределяет разрешения POSIX на файлы/папки. Таким образом, даже несмотря на то, что папка, о которой идет речь, могла быть 777 с запуском root, команда SELinux была включена и, в свою очередь, перезаписывала те разрешения, которые выдавали "разрешение отказало" -error от rsync.

Вы можете запустить команду getenforce, чтобы увидеть, включено ли на машине SELinux.

В моей ситуации я просто отключил SELINUX полностью, потому что он не был нужен и уже отключен на сервере, который работал нормально и только вызвал проблемы. Чтобы отключить, откройте /etc/selinux/config и установите SELINUX=disabled. Чтобы временно отключить, вы можете запустить команду setenforce 0, которая установит SELinux в состояние permissive, а не состояние enforcing, которое заставляет его печатать предупреждения вместо принудительного применения.

Ответ 3

Демон Rsync по умолчанию использует nobody/nogroup для всех модулей, если он запущен под пользователем root. Таким образом, вам нужно либо определить параметры uid и gid для пользователя, которого вы хотите, либо установить для них root/root.

Ответ 4

Я столкнулся с той же проблемой и решить ее chown пользователя папки назначения. У текущего пользователя нет прав на чтение, запись и выполнение файлов папки назначения. Попробуйте добавить разрешение с помощью chmod a+rwx <folder/file name>.

Ответ 5

У меня была аналогичная проблема, но в моем случае это было потому, что хранилище имеет только SFTP, без демонов ssh или rsync. Я ничего не мог изменить, bcs этот сервер был предоставлен моим клиентом.

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.

вы можете найти man по ссылке lftp.yar.ru/lftp-man.html

Ответ 6

Это может не устраивать всех, поскольку оно не сохраняет исходные разрешения файлов, но в моем случае это было неважно, и он решил проблему для меня. rsync имеет опцию --chmod:

- chmod Этот параметр сообщает rsync применять одну или несколько разделенных запятыми строк lqchmodrq к разрешению файлов в передаче. результирующее значение обрабатывается так, как если бы это были разрешения, что отправляющая сторона, предоставленная для файла, что означает, что эта опция может похоже, не влияют на существующие файлы, если --perms не включен.

Это заставляет разрешения быть такими, какие вы хотите для всех файлов/каталогов. Например:

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

добавит Read, Write и Execute для всех переданных каталогов.

Ответ 7

Windows: проверьте права доступа к папкам назначения. Соблюдайте права собственности, если вы должны предоставить права на учетную запись, запущенную службой rsync.

Ответ 8

Я полагаю, что общая ошибка, о которой не упоминалось выше, пытается записать в пространство монтирования (например, /media/drivename), когда раздел не установлен. Это также приведет к этой ошибке.

Если зашифрованный диск настроен на автоматическое монтирование, но это не так, может возникнуть проблема автоматической разблокировки зашифрованного раздела, прежде чем пытаться записать его в пространство, где он должен быть установлен.

Ответ 9

У меня была такая же ошибка при синхронизации файлов внутри контейнера Docker, а пункт назначения был установленным томом (Docker для mac), я запускаю rsync через su-exec <user>. Я смог разрешить его, выполнив rsync как root с флагами -og (сохранить владельца и группу для файлов назначения).

Я все еще не уверен, что вызвало эту проблему, права доступа были в порядке (я запускаю chown -R <user> для целевого каталога до rsync), возможно, каким-то образом связанным с медленной файловой системой Docker for Mac.

Ответ 10

У меня была такая же проблема в случае CentOS 7. Я просмотрел много статей, форумов, но не смог найти решение. Проблема была с SElinux. Отключение SElinux на стороне сервера сработало. Проверка состояния SELinux на стороне сервера (откуда вы извлекаете данные с помощью rysnc) Команды для проверки состояния SELinux и его отключения

$ getenforce

Применение ## означает, что SElinux включен

$ setenforce 0

$ getenforce

диспозитивный

Теперь попробуйте запустить команду rsync на стороне клиента, у меня это сработало. Всего наилучшего!

Ответ 11

Обратите внимание на -e ssh и jenkins @localhost: в следующем примере:

rsync -r  -e ssh --chown=jenkins:admin --exclude .git --exclude Jenkinsfile --delete ./ [email protected]:/home/admin/web/xxx/public

Это помогло мне

PS Сегодня я понял, что когда вы меняете (добавляете) пользователя jenkins в какую-либо группу, разрешение будет применяться после перезапуска подчиненного (агента). И мое решение (-e ssh и jenkins @localhost:) нужно только тогда, когда вы не можете перезапустить агент/сервер.

Ответ 12

У меня есть сервер Centos 7 с rsyncd на борту: /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 - это простое, но не очень хорошее решение

Ответ 13

Удивительно, но никто не упомянул все мощные СУДО. Если бы та же самая проблема и sudo ее исправили

Ответ 14

запустить в корневом доступе ssh может решить эту проблему

или chmod 0777 /dir/to/be/backedup/

или chown username:user /dir/to/be/backedup/