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): util-linux-2.13-0.20.1 How reproducible: $ 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 Actual results: the bind mount is mounted instead of the filesystem Expected results: filesystem mounted Note: 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 another. The core problem is that # mount x will match two lines in /etc/fstab (or /etc/mtab): x blah blah x 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. ***