find:ファイルシステムループが検出されました


9

を使用してファイルを検索しようとするとfind -name "filename"、次のエラーが表示されます。

./var/named/chroot/var/named' is part of the same file system loop as `./var/named'

ls -ldi /var/named/chroot/var/named/ /var/namedコマンドを実行しましたが、iノード番号は同じです。調査によると、修正はハードリンク/var/named/chroot/var/named/を使用して削除し、rm -fそれをディレクトリとして再作成することですが、これを行うと、すでにディレクトリであるため削除できないことをお勧めします。どうすれば修正できますか?Centos 6とPlesk 11を実行しています。

mountコマンドはこれを与えます:

/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type tmpfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/etc/named on /var/named/chroot/etc/named type none (rw,bind)
/var/named on /var/named/chroot/var/named type none (rw,bind)
/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)
/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)
/usr/lib64/bind on /var/named/chroot/usr/lib64/bind type none (rw,bind)
/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)
/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)

回答:


9

named、つまりDNSサーバーであり、chrootで実行されます。構成ファイルにアクセスするために、起動スクリプトはmount --bindを使用して構成ディレクトリをchroot内に表示します。この手段/var/named/と同じであり/var/named/chroot/var/named、そして/var/named/chroot/var/named/chroot/var/namedようにと。これは再帰的なディレクトリ構造であるため、findすべてを横断しようとすると、実行を終了することはできません。そのため、2つのディレクトリが実際には同じであることがわかり、警告メッセージが表示されます。

メッセージは、以前に見た他のディレクトリと同じであることを認識したため、find内部を検索しないことを意味します/var/named/chroot/var/named。これは完全に無害なメッセージです。無視しても問題ありません。スキップし/var/named/chroot/var/namedた後、find操作は通常どおり続行されます。


このステートメントの後に何もない場合、それは単にファイルが見つからなかったことを意味しますか?
user1780242

はい、そうだと思います。存在することがわかっているファイルで同じことを試してください。また、コマンドラインに「2> / dev / null」を追加するエラーメッセージを抑制できます。
pqnet

1

メッセージは戻りコード1をトリガーし、無視できず、リダイレクトも機能しません。

findutilsを使用するfindutils-4.4.2-6.el6.x86_64

これは対応するバグレポートのようです:

Linuxカーネルを実行しているシステムでは、「find -printf%F」は、「mount --bind」を使用して別の場所に再マウントされたファイルシステム上のファイルに対して誤った回答を生成しなくなりました。(サバンナのバグ#14921)。

影響を受けるスクリプトを修正できない場合(つまり、サードパーティによって作成されたため)の(セキュリティ上の課題)解決策は、少なくとも一時的にbind-chrootパッケージを削除することです。


0

ハードリンクだとは思いません。通常、ディレクトリのハードリンクは禁止されています。私はソフトリンクかもしれないが、それはマウントループだように見えます:と思われ/var/namedたり、多分/varに再び装着されています/var/named/chroot。多分それはバインドマウント(mount -o bind)または単なる通常のマウントです。

mountコマンドの出力を投稿できますか?また、おそらくこれはchroot jailに必要なマウントであり、そのままにしておく方がよいでしょう。


可能性があるmount --bindことがchroot環境で動作する唯一のものですので。
pqnet 2014

0

この問題はnamed、が/var/namedディレクトリをマウントするinitスクリプトが原因で発生し/var/named/chrootます。この問題の解決策もinitスクリプトにあります。

mount_chroot_conf()
{
   # Mount source is a directory. Mount it only if directory in chroot is
   # empty.

上記のように、mount関数はディレクトリが空の場合にのみ機能します。したがって、以下のソリューションを使用してください:

  1. やめる named
  2. ディレクトリを作成する /var/named/chroot/var/named
  3. このディレクトリ内に空のファイルを作成します
  4. 開始 named
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.