Red Hat Bugzilla – Bug 193094
'mount' mounts wrong filesystem with bind mounts
Last modified: 2008-03-09 06:30:49 EDT
Description of problem:
mount can accept either a device node or a mountpoint if the filesystem is
in /etc/fstab. unfortunately, with bind (and loop) mounts, a file or directory
can appear as both the device node or the mountpoint (in different entries),
making a simple 'mount /blah' ambiguous.
Version-Release number of selected component (if applicable):
$ grep /test /etc/fstab
/dev/VolGroup00/tmp /test ext3 defaults 0 0
/test /test1 none bind 0 0
$ sudo mount /test
-> /test1 mounted instead of /test.
Steps to Reproduce:
1. have a filesystem in /fstab also be the source of a bind mount
2. try to mount it
the bind mount is mounted instead of the filesystem
bind mounts are important for nfs4 exports and for setting chrooted
environments (FC5-in-FC4, etc.)
Created attachment 129975 [details]
fix - ignore device nodes that are regular files or directories
It's not so simple. Your patch completely disable mount by /path/file.img for
loop devices. You also forget that no all people use ambiguous configuration and
use bind mount by source directories is fine for them.
I think rather than add to code some non-transparent heuristic is better use for
example mount by LABEL/UUID/device for your /dev/VolGroup00/tmp.
bind mounts cannot use LABEL/UUID/device.
Perhaps disambiguate by using a prefix:
mount device:/path/file.img # by device
mount /dev/devicenode # by device
mount /path/mountpoint # by mountpoint
I can do the patch.
Well, I didn't talk about LABEL/UUID/device for bind mount. Let's use:
mount /dev/VolGroup00/tmp (or mount LABEL=foo)
when you need mount the device and
mount /test1 (or mount /test, because the mount checks fs_spec before fs_file)
when you need bind mount.
This removes the ambiguity for the case I mentioned, but is ambiguous for
The core problem is that
# mount x
will match two lines in /etc/fstab (or /etc/mtab):
unless we disambiguate, somebody will hit this. I know I did, and silently
unexpected behavior with mount/umount can easily be disasterous.
*** Bug 242935 has been marked as a duplicate of this bug. ***