GNU bug report logs - #28670
df: detect over-mounted filesystems

Previous Next

To reply to this bug, email your comments to 28670 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Jenkins <alan.christopher.jenkins <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: df: detection of overmounted filesystems is not quite complete
Date: Mon, 2 Oct 2017 13:27:02 +0100

Scenario 1 - lovely diagnostic

$ df -h /dev/sda1
df: cannot access '/dev/sda1': over-mounted by another device

$ mount | grep boot/efi
/dev/sda6 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
none on /boot/efi type tmpfs (rw,relatime,seclabel)


Scenario 2 - breaks down

$ df -h |grep /dev/sda1
$ df -ah |grep /dev/sda1
/dev/sda1                             -     -     -    - /boot/efi

above is consistent (same output as in scenario 1), but below is bad:

$ df -h /dev/sda1  # or same output  from `/boot/efi`
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       3.9G     0  3.9G   0% /boot/efi

Case 2 situation is as follows:

$ mount | grep boot
/dev/sda6 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
/dev/sda1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
none on /boot type tmpfs (rw,relatime,seclabel)

i.e. the tmpfs on /boot is the most recent mount, masking the /boot/efi 
mount (and I created a dummy `/boot/efi` directory in the tmpfs).

The practical use-case is that people get very confused when their 
distribution sets up pam_ecryptfs.  If `df` was more reliable about 
detecting overmounts, then it would provide better diagnostics for when 
pam_ecryptfs overmounts a filesystem which was mounted by fstab.

https://unix.stackexchange.com/questions/370043/mounting-a-subdirectory-of-home-onto-an-own-partition-confuses-disk-usage-report/395630?noredirect=1#comment706009_395630

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Jenkins <alan.christopher.jenkins <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Re: df: detection of overmounted filesystems is not quite complete
Date: Mon, 2 Oct 2017 13:28:14 +0100

$ rpm -q --whatprovides `which df`
coreutils-8.27-6.fc26.x86_64

(Fedora Linux 26)


On 02/10/17 13:27, Alan Jenkins wrote:
> Scenario 1 - lovely diagnostic
>
> $ df -h /dev/sda1
> df: cannot access '/dev/sda1': over-mounted by another device
>
> $ mount | grep boot/efi
> /dev/sda6 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
> /dev/sda1 on /boot/efi type vfat 
> (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
> none on /boot/efi type tmpfs (rw,relatime,seclabel)
>
>
> Scenario 2 - breaks down
>
> $ df -h |grep /dev/sda1
> $ df -ah |grep /dev/sda1
> /dev/sda1                             -     -     -    - /boot/efi
>
> above is consistent (same output as in scenario 1), but below is bad:
>
> $ df -h /dev/sda1  # or same output  from `/boot/efi`
> Filesystem      Size  Used Avail Use% Mounted on
> /dev/sda1       3.9G     0  3.9G   0% /boot/efi
>
> Case 2 situation is as follows:
>
> $ mount | grep boot
> /dev/sda6 on /boot type ext4 (rw,relatime,seclabel,data=ordered)
> /dev/sda1 on /boot/efi type vfat 
> (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
> none on /boot type tmpfs (rw,relatime,seclabel)
>
> i.e. the tmpfs on /boot is the most recent mount, masking the 
> /boot/efi mount (and I created a dummy `/boot/efi` directory in the 
> tmpfs).
>
> The practical use-case is that people get very confused when their 
> distribution sets up pam_ecryptfs.  If `df` was more reliable about 
> detecting overmounts, then it would provide better diagnostics for 
> when pam_ecryptfs overmounts a filesystem which was mounted by fstab.
>
> https://unix.stackexchange.com/questions/370043/mounting-a-subdirectory-of-home-onto-an-own-partition-confuses-disk-usage-report/395630?noredirect=1#comment706009_395630 
>

Message #11 received at 28670 <at> debbugs.gnu.org (full text, mbox):

From: Alan Jenkins <alan.christopher.jenkins <at> gmail.com>
To: 28670 <at> debbugs.gnu.org
Subject: Re: df: detection of overmounted filesystems is not quite complete
Date: Mon, 2 Oct 2017 16:54:58 +0100

> Report bugs, including version and distribution variant, to the list ...

oops.  Fedora Linux 26:

$ rpm -q --whatprovides `which df`
coreutils-8.27-6.fc26.x86_64

Message #14 received at 28670 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Stephane Chazelas <stephane.chazelas <at> gmail.com>, 28991 <at> debbugs.gnu.org,
 28670 <at> debbugs.gnu.org
Subject: Re: bug#28991: df: wrong output when a FS masks another one
Date: Wed, 25 Oct 2017 21:48:09 -0700

On 25/10/17 07:57, Stephane Chazelas wrote:
> Test case:
> 
> /tmp$ mkdir -p 1/2
> /tmp$ sudo mount -o size=1M -t tmpfs x 1/2
> /tmp$ sudo mount -o size=2M -t tmpfs y 1
> /tmp$ mkdir 1/2
> /tmp$ df -h 1/2
> Filesystem      Size  Used Avail Use% Mounted on
> x               2.0M     0  2.0M   0% /tmp/1/2
> 
> The Size is correct as that's obtained from statfs() on the
> file. But when it comes to finding the corresponding mount
> source and mountpoint, it fails.
> 
> /tmp$ grep /tmp/ /proc/mounts
> x /tmp/1/2 tmpfs rw,relatime,size=1024k 0 0
> y /tmp/1 tmpfs rw,relatime,size=2048k 0 0
> 
> df should walk /proc/self/mounts or /etc/mtab from the bottom up
> until it finds the first mount point that is a parent of the
> realpath of the file.
> 
> /tmp$ df --version
> df (GNU coreutils) 8.28
> 
> (on Debian testing amd64)
> 
> 
> Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15955
> 
> That's just been discussed on the austin group mailing list:
> https://www.mail-archive.com/austin-group-l <at> opengroup.org/msg01715.html
> https://www.mail-archive.com/austin-group-l <at> opengroup.org/msg01720.html
> 
> Not critical as that could be considered as a pathological test
> case.
> 

Yes it would be nice to behave more consistently here.
Also related is https://bugs.gnu.org/28670

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.