ユーザー:-root
/usr/bin/rsync -hprltaq --include '*/' --include '*.gz' --exclude '*' "/var/cache/backup/backup-20210817mysql.tar.gz" <storage_IP>::my-app/backup/sql_backup/
エラー: -->
rsync: chgrp "/backup/sql_backup/.backup-20210817mysql.tar.gz.nWPkhd" (in my-app) failed: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]
rsyncでエラーが発生しても、ファイルはターゲット（ストレージサーバー）にコピーされます。
ストレージサーバーに対する権限
ls -al backup/
drwxr-xr-x 9 nobody nogroup 4096 Oct 3 2020 .
drwxr-xr-x 81 nobody nogroup 12288 Aug 17 08:00 ..
drwxrwxrwx 2 nobody nogroup 4.0K Aug 17 12:54 sql_backup
777 権限も試しましたが、同じエラーが発生しました。
ベストアンサー1
指定した（）フラグ-aには、ターゲットファイル/ディレクトリの所有者とグループをソースプロジェクトの所有者とグループに設定する要求が含まれています。ストレージサーバーがrsyncサービスをrootとして実行しているようには見えず、サービスを実行しているユーザーがソースファイルを所有しているグループのメンバーではありません。--archiversync/var/cache/backup/backup-20210817mysql.tar.gz
3つの可能な解決策を見ることができます。
ストレージサーバーのファイルシステムで拡張属性を使用できるかどうかをテストし、その場合はそれを使用して所有者/グループやその他の便利なメタデータを保存します。
rsync -M--fake-super --numeric-ids -ahq ...これが最善の解決策になります。ファイルを保存して復元するには常に
-M--fake-super--numeric-ids。ストレージサーバーに書き込まれたメタデータから所有者/グループIDを削除します。その後、この「手動」復元の責任はあなたにあります。
rsync -ahq --no-o --no-g ...ストレージシステムでrootとしてサービスを実行します。これは、Linux / UNIXベースのオペレーティングシステムでサービス所有者を変更し、リスクを負うことができると仮定します。お勧めできませんが、可能性として記載されています。