find: File system loop detected

Question

When I try to find a file using find -name "filename" I get an error that says:

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

I ran the ls -ldi /var/named/chroot/var/named/ /var/named command and the inode numbers are the same. Research indicates the fix is to delete the hard link /var/named/chroot/var/named/ using rm -f and recreate it as a directory but when I do this I am advised that it can't be deleted because it is a directory already. How do I fix this? I'm running Centos 6 with Plesk 11.

The mount command gives this:

/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)

Answer 1

named, that is the DNS server, runs in a chroot. To access the configuration file, the startup script uses mount --bind to make the configuration dir visible inside the chroot. This means that /var/named/ is the same as /var/named/chroot/var/named, and /var/named/chroot/var/named/chroot/var/named and so on. This is a recursive directory structure so if find tried to transverse it all it would never be able to terminate its execution, so it realizes that the two directory are actually the same, and prints you that message, to warn you.

The message means that find won't search inside /var/named/chroot/var/named because it realized it is the same as some other directory already seen before. It is a totally harmless message, you can safely ignore it: after skipping /var/named/chroot/var/named the find operation continues normally.

Answer 2

The message triggers a returncode 1 and can't be ignored, nor will redirection work.

Using findutils findutils-4.4.2-6.el6.x86_64

It seems this is the corresponding bug report:

On systems running the Linux kernel, "find -printf %F" no longer produces the wrong answer for files on filesystems that have been remounted elsewhere using "mount --bind". (Savannah bug #14921).

A (security challenged) solution if you can't fix the affected script (i.e. because it was written by a 3rd party) is to remove the bind-chroot package, at least temporarily.

Answer 3

I don't think it's a hard link. Usually directory hard links are forbidden. I could be a soft link, but it looks like it's a mount loop: it seems that /var/named or maybe /var is mounted again on /var/named/chroot. Maybe it's a bind mount (mount -o bind) or just a normal mount.

Can you post the output of your mount command? Also, maybe this is a mount needed for the chroot jail and you better leave it.

Answer 4

The problem is caused by the init script of named which mounts the /var/named directory over /var/named/chroot. The solution for this problem too is present in the init script.

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

As mentioned above the mount function will work only if the directory is empty. So use the below solution:

1. Stop named
2. Create the directory /var/named/chroot/var/named
3. Create an empty file inside this directory
4. Start named