サーバーAからサーバーBに定期的にファイルをrsyncするために、次のセットアップがあります。サーバー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/ [email protected]::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を使用するとこれが解決されることがわかりました
Rsyncがフォルダ自体の変更時間を更新しようとしたため、リモートマシンでrsyncを実行するユーザーに、フォルダの内容とフォルダ自体への書き込みアクセス権があることを確認してください。
あなたがこれを機能させたにもかかわらず、最近同様の出会いがあり、SOまたはGoogle検索はすべての基本的な許可の問題を扱っていたので助けにはなりませんでしたほとんどの状況ではチェックすることすら考えないでしょう。
許可を確認する1つのことは、所有者とグループを含む両方のサーバーで許可がまったく同じであるが、rsync転送は一方のサーバーで一方向に機能したが、他の方法では機能しなかったという問題を自分で最近発見したことを否定しました。
SELinuxが有効になっていて、ファイル/フォルダーのPOSIX許可が無効になっているため、許可が拒否されていた問題がサーバーに判明しました。そのため、問題のフォルダーはrootが実行されている777であっても、コマンドSELinuxが有効になり、rsyncから「permission denied」エラーを生成する許可が上書きされます。
コマンドgetenforce
を実行して、マシンでSELinuxが有効になっているかどうかを確認できます。
私の状況では、SELINUXは不要であり、正常に機能していて問題が有効になったサーバーで既に無効になっているため、SELINUXを完全に無効にしました。無効にするには、/etc/selinux/config
を開き、SELINUX=disabled
を設定します。一時的に無効にするには、setenforce 0
コマンドを実行します。これにより、SELinuxはpermissive
状態ではなくenforcing
状態に設定され、強制ではなく警告が出力されます。
Rsyncデーモンは、rootユーザーで実行されている場合、デフォルトですべてのモジュールにnobody/nogroupを使用します。そのため、パラメーターuid
およびgid
を必要なユーザーに定義するか、root/rootに設定する必要があります。
私は同じ問題に遭遇し、chown
宛先フォルダーのユーザーによってそれを解決しました。現在のユーザーには、宛先フォルダーファイルの読み取り、書き込み、実行の権限がありません。 chmod a+rwx <folder/file name>
で許可を追加してみてください。
元のファイルのアクセス許可が保持されないため、これはすべての人に適しているわけではありませんが、私の場合は重要ではなく、問題を解決しました。 rsyncにはオプション--chmod
:
-chmodこのオプションは、1つ以上のコンマ区切りのlqchmodrq文字列を転送中のファイルの許可に適用するようにrsyncに指示します。結果の値は、送信側がファイルに提供した許可であるかのように扱われます。つまり、-permsが有効になっていない場合、このオプションは既存のファイルに影響を与えないように見えます。
これにより、すべてのファイル/ディレクトリで必要な権限が許可されます。例えば:
rsync -av --chmod=Du+rwx SRC DST
転送されたすべてのディレクトリにユーザーの読み取り、書き込み、実行を追加します。
私も同様の問題を抱えていましたが、私の場合は、ストレージに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-PC上のフォルダー、/ rem/folder-sftp://sft.domain.tld/rem/folderです。
リンクlftp.yar.ru/lftp-man.htmlでmanを見つけることができます
Windows:宛先フォルダーの許可を確認します。 rsyncサービスを実行しているアカウントに権限を付与する必要がある場合は、所有権を取得します。
現在上記で言及されていない一般的なエラーは、マウントスペース(たとえば、/media/drivename
)パーティションがマウントされていない場合。このエラーも発生します。
暗号化されたドライブが自動マウントに設定されているがそうでない場合、マウントされるはずのスペースに書き込む前に暗号化されたパーティションの自動ロック解除の問題である可能性があります。
次の例で-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:)は、エージェント/サーバーを再起動できない場合にのみ必要です。
CentOS 7でも同じ問題が発生しました。多くの記事、フォーラムを読みましたが、解決策が見つかりませんでした。問題はSElinuxにありました。サーバー側でのSElinuxの無効化は機能しました。サーバーエンドでのSELinuxステータスの確認(rysncを使用してデータをプルしている場所)SELinuxステータスを確認して無効にするコマンド
$ getenforce
強制##これは、SElinuxが有効であることを意味します
$ setenforce 0
$ getenforce
寛容
今、クライアント側でrsyncコマンドを実行してみてください、それは私のために働いた。ではごきげんよう!
ボードに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を無効にするのは簡単ですが、良い解決策ではありません
Dockerコンテナー内のファイルを同期しているときに同じエラーが発生し、宛先がマウントされたボリューム(Mac用のDocker)であったため、su-exec <user>
経由でrsync
を実行しました。 rsync
をroot
として-og
フラグ(宛先ファイルの所有者とグループを保持)として実行することで解決できました。
なぜその問題の原因がわからないのか、宛先のアクセス許可がOKだった(rsync
の前に宛先ディレクトリに対してchown -R <user>
を実行した).
驚くべきことに、誰もがすべての強力な須藤について言及していません。同じ問題があり、須藤はそれを修正しました