7

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)

migrated from serverfault.com Sep 4 '14 at 15:12

This question came from our site for system and network administrators.

7

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.

  • So if there's nothing after this statement, it simply means the file wasn't found? – user1780242 Sep 4 '14 at 16:04
  • yes, guess so. Try the same with a file that you know that exists. Also, you can suppress error messages adding ` 2> /dev/null` to the command line. – pqnet Sep 5 '14 at 0:32
1

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.

0

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.

  • it is likely to be a mount --bind because it is the only thing that works in a chroot. – pqnet Sep 4 '14 at 15:10
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.