-   Linux - General (
-   -   Strange entry in `df` (df: `/var/named/chroot/proc': Permission denied) (

BWebb 09-14-2006 08:57 AM

Strange entry in `df` (df: `/var/named/chroot/proc': Permission denied)
Dell OptiPlex P4 3GHz
CentOS 4.3
kernel 2.6.9-42.0.2.ELsmp
updating with yum

Okay everyone, I have never seen this before and I don't know what caused it either. Over the past month I have setup about 8 nearly identical systems --- Dell PCs (various chips) running CentOS 4.3 --- and none of the other systems are experiencing this problem. I have checked all of the logs in /var/log/ and nothing pops out at me. Before I get to the problem, there is one difference between this machine and the others I have set up: this one is running a local DNS nameserver for the local network.

The Problem:

When I run `df` as root I get the following output:
Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00
74730664 46705240 24229252 66% /
/dev/sda1 101086 25816 70051 27% /boot
none 516584 0 516584 0% /dev/shm
/dev/sdb1 196015808 146570920 39487804 79% /home2
/dev/sdc1 480719056 26721340 429578516 6% /media/usbdisk

Okay, that all look hunky-dory. For the curious at heart, /dev/sda is the primary 80G harddrive which contains the OS, /dev/sdb is a second internal harddrive with 1 ext3 partition (sdb1), and /dev/sdc is an 500G external WesternDigital USB disk with 1 ext3 partition (sdc1).

Now, when I run `df` as a regular user I get the following output:
Filesystem 1K-blocks Used Available Use% Mounted on
74730664 46705236 24229256 66% /
/dev/sda1 101086 25816 70051 27% /boot
none 516584 0 516584 0% /dev/shm
df: `/var/named/chroot/proc': Permission denied
/dev/sdb1 196015808 146570924 39487800 79% /home2
/dev/sdc1 480719056 26721340 429578516 6% /media/usbdisk

Huh? Why is /var/named/chroot/proc showing up in the output of df? I have never seen this before. And what is /proc doing in the /var/named/chroot/ directory anyways? I thought the only things that belonged in there were dev/ etc/ and var/? That's how it is on every other machine I have seen... I don't see how this could be a function of me setting up a DNS (running named) nameserver on this machine, but it is the only immediately recognizable difference between the systems.

Is there a gremlin in the machine or what? I got a little scared yesterday when I couldn't access the second harddrive (/dev/sdb1 mounted to /home2) and was wondering if something was wreaking havoc inside the machine. I upgraded to the most recent kernel (2.6.9-42.0.2.ELsmp) and rebooted in hopes of fixing the problem. Uhoh, the BIOS didn't even see the second harddrive... it's as if it just disappeared. I thought that perhaps the disk was corrupt, but that wouldn't explain why the BIOS couldn't find it. So, I cracked open the machine and plugged the disk into a different SATA port and rebooted. Yep, BIOS picked it up and it booted just fine. I ran e2fsck on /dev/sdb1 and it said it was clean. Very strange... do SATA ports frequently just bonk out or what? This could be related or unrelated to my `df` problems, but either way I thought I would mention it... always better to have more information than not enough.

Anyhow, if anyone else has experienced this problem or knows where to go hunting I would appreciate it. I Googled for a while, but the information seemed unrelated to the problem that I am having.



BWebb 09-14-2006 11:08 AM

Perhaps an answer to my own question?
Spoke with someone about this problem today. Turns out that since I am running named (DNS nameserver) chroot'ed, it has to mount proc/ in the /var/named/chroot/ directory because it contains files that named needs. Since proc/ is showing up in the /var/named/chroot directory, a normal user wouldn't be able to make any inquiries about it. However, this doesn't really explain why `df` reports information about it.

As it turns out, it is a mildly annoying yet harmless problem. I just deleted the line in /etc/mtab to get rid of the annoyance. However, `df` shouldn't even be concerned with entries of size 0, so I don't know why the line was added to /etc/mtab.


All times are GMT -5. The time now is 11:16 AM.