Bug 730138

Summary:	mount / df broken in F15
Product:	[Fedora] Fedora	Reporter:	Harald Reindl <h.reindl>
Component:	coreutils	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	15	CC:	kdudka, maxamillion, ovasik, twaugh
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-12 05:37:48 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Harald Reindl 2011-08-11 21:01:17 UTC

with the behavior below EVERY tool working with the output of "df" used in cron-scripts results in a amil about the missing permissions for 
/var/named/chroot/

"/dev/sdd1" has two bind-mounts but appears THREE times in "df" AND in theoutput of "mount", this breaks the ignoring of bind-mounts in mlocate and thousands of other things - how can it be that such buggy changes are released as GA and not fixed over months?

[harry@srv-rhsoft:~]$ /bin/df -hT
Dateisystem   Typ    Größe Benut  Verf Ben%% Eingehängt auf
rootfs      rootfs     25G   11G   15G  41% /
udev      devtmpfs    3,9G     0  3,9G   0% /dev
tmpfs        tmpfs    1,0G  212K  1,0G   1% /dev/shm
tmpfs        tmpfs    4,0G  3,0M  4,0G   1% /run
/dev/sda2     ext4     25G   11G   15G  41% /
tmpfs        tmpfs    4,0G     0  4,0G   0% /sys/fs/cgroup
tmpfs        tmpfs    4,0G     0  4,0G   0% /media
tmpfs        tmpfs    4,0G  3,0M  4,0G   1% /var/run
tmpfs        tmpfs    4,0G  3,0M  4,0G   1% /var/lock
tmpfs        tmpfs    150M  228K  150M   1% /var/www/sessiondata
/dev/sda1     ext4    244M   43M  201M  18% /boot
/dev/sdc1     ext4    932G  773G  159G  83% /mnt/fileserver
/dev/sdd1     ext4    459G  285G  174G  63% /mnt/data
/dev/sdd1     ext4    459G  285G  174G  63% /Volumes/dune/www-servers
/dev/sdd1     ext4    459G  285G  174G  63% /Volumes/dune/www-servers/phpincludes
/dev/sda6     ext4    5,0G  258M  4,7G   6% /var/log
/dev/sda7     ext4     20G 1022M   19G   6% /home
/dev/sda5     ext4     25G  176M   25G   1% /var/spool
/dev/sda8     ext4     20G  172M   20G   1% /mnt/downloads
/dev/sda3     ext4    6,0G  256M  5,7G   5% /var/cache
/dev/sda9     ext4     20G  333M   20G   2% /tmp
/bin/df: „/var/named/chroot/etc/named“: Keine Berechtigung
/bin/df: „/var/named/chroot/usr/lib64/bind“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.iscdlv.key“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.root.key“: Keine Berechtigung

Comment 1 Ondrej Vasik 2011-08-12 05:37:48 UTC

Thanks for report, unfortunately there is not much I can do about it at the moment - this is what is in /proc/mounts (or better said what is provided by mountlist() ) and df is just using it - there were already several threads on fedora-devel and upstream afaik with no clear solution. Anyway - already reported, so closing as DUPLICATE of #709351.

*** This bug has been marked as a duplicate of bug 709351 ***

Comment 2 Harald Reindl 2011-08-12 08:29:02 UTC

why did nobody cry out loud BEFORE release and try to force the idiots upstream on wahtever package to revert their solution for non-existing problems while damaging all sort of programs and why is there nothing happening over months?

every packger says "i can not do anything"
wrong!

you CAN -> file bugreports at the root of the problem and if enough peopole with @redhat.com would do this upstream would start thinking that they did really something badly wrong!

Comment 3 Ondrej Vasik 2011-08-12 08:54:22 UTC

Well, change of /etc/mtab to symlink to /proc/mounts was caused/requested by systemd changes (very late in release cycle - after some freezes of F15...) and there was a lot of loud crying on fedora-devel list - but it still went out. Btw. at least @redhat.com are upstream maintainers of coreutils (no, not me), and there was already discussion how to deal with it. As I said, no clear solution so far... see the duplicate bugzilla if you are interested in the discussions and (known) issues.

The root of the problem is outside of coreutils and is well known by the (upstream) people - but I really can't do anything with this - except some nasty hacks which I really don't plan to do...

Comment 4 Harald Reindl 2011-12-24 23:58:40 UTC

so do this hacks or treat upstream or whatever

it is UNACCEPTABLE get this stupid "access denied" messages and endless mount-lists over months and years - i have here a server with 300 automatically maintained bind-mounts for chrooted sftp-users as example


this i can no longer see because it breaks ECERY cronjob which is running with non-root privileges resulting in cron-mals as long you do not supress errors with " 2> /dev/null" wthat is a more than ugly hack since you supress real errors also

/bin/df: „/var/named/chroot/etc/named“: Keine Berechtigung
/bin/df: „/var/named/chroot/usr/lib64/bind“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.iscdlv.key“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.root.key“: Keine Berechtigung