mount (silently) ignores options for bind mounts

Bug #712892 reported by AmenophisIII on 2011-02-04
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Fix Released
util-linux (Ubuntu)

Bug Description

Binary package hint: util-linux

mount ignores any options given for bind mounts and adds an incorrect line to mtab.
there is (at least) one exception: the option ro (== read-only). it warns that the bind mount is mounted read-write, if one tries to use that option together with bind.

some examples of the current behavior (with comments):
~/bla# mkdir foo
~/bla# mkdir bar
~/bla# touch foo/test
~/bla# mount foo/ bar/ -obind,ro
mount: warning: bar/ seems to be mounted read-write.
# at least it says so
~/bla# rm bar/test
~/bla# ls bar/test
ls: cannot access bar/test: No such file or directory
# expected after that warning
~/bla# touch foo/test
~/bla# mount foo/ bar/ -obind,somebogusoption1
~/bla# mount foo/ bar/ -obind,somebogusoption2
~/bla# mount foo/ bar/ -obind,somebogusoption3
~/bla# mount
/root/bla/foo on /root/bla/bar type none (rw,bind)
/root/bla/foo on /root/bla/bar type none (rw,bind,somebogusoption1)
/root/bla/foo on /root/bla/bar type none (rw,bind,somebogusoption2)
/root/bla/foo on /root/bla/bar type none (rw,bind,somebogusoption3)
# mount adds bogus lines to mtab...
~/bla# ls bar/
# but at least it does mount
umount bar
/root/bla/foo on /root/bla/bar type none (rw,bind)
/root/bla/foo on /root/bla/bar type none (rw,bind,somebogusoption1)
/root/bla/foo on /root/bla/bar type none (rw,bind,somebogusoption2)
# and umount only removes one (bogus) line per execution :)

the behavior is kinda documented in the manpage (well the bogus lines are clearly a bug (two actually), but i don't care right now).
a workaround is to first bind mount and then use the remount option for setting other options e.g.:
~/bla# mount foo/ bar/ -obind
~/bla# mount bar/ -oremount,ro
~/bla# rm bar/test
rm: cannot remove `bar/test': Read-only file system

the problem is... this does not work with fstab:
neither setting up one line with options bind,ro such as
/root/bla/foo /root/bla/bar none bind,ro
(this gives the same warning as above)
nor using two, one with the remount option:
/root/bla/foo /root/bla/bar none bind
/root/bla/foo /root/bla/bar none remount,ro
(this even fails silently to remount read-only!)

the warning was introduced by Karel Zak in november 2009. i read that debian had a patch for correcting at least some of the issues above, but i could not find anything.
one workaround for certain situations could be to use pam_mount.

this war reported/tested on ubuntu 10.10 with kernel 2.6.35-25 and mount 2.17.2-0ubuntu1.10.10.1.

AmenophisIII (amenophisiii) wrote :

i hacked together a patch that retries to bind mount once with MS_REMOUNT added to the flags instead of printing out the warning. it seems to work, but i don't have the insights if it may break anything.
with this it is possible to bind mount a directory in fstab with options "bind,ro", as well as mounting it on the command line in one line (without remount,ro).

it does not address other issues mentioned in my original report.

jones please comment! thanks

Changed in util-linux-ng:
status: Unknown → New
tags: added: patch
Scott Moser (smoser) wrote :

Thank you for taking the time to open a thorough bug report and also submit a patch.

I can't personally think of any fallout of the suggested changes, but it does seem that it would be best to run this behavior by upstream first, and there have been other discussions on such changes [1]. That discussion at least resulted in a warning that the warning you show above.

I think it would be probably best to post this upstream and see what their response is. Upstream has mailing list info at [2].


On Fri, 18 Mar 2011 20:05:19 -0000
Scott Moser <email address hidden> wrote:

> I think it would be probably best to post this upstream and see what
> their response is. Upstream has mailing list info at [2].

i thought so too. this is what karel said: "I'm still not sure if
mount(8) is the right place to fix odd kernel behaviour. Anyway, your
patch seems like a usable workaround.

I'll try to apply the patch later (it will necessary to modify
libmount, because the library is not able to add a new entry to mtab
for MS_REMOUNT requests)."

maybe on could convince the kernel guys to think over the underlying
problem, but i don't have enough insights to do a good enough bug report
and argue with them. i skimmed through the kernel's mounting source, but
it's not as easy understandable as mount itself :)
maybe someone at canoncial could try?

lg, ameno

Kees Cook (kees) on 2011-04-08
Changed in util-linux (Ubuntu):
status: New → Triaged

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 712892

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Phillip Susi (psusi) on 2013-10-10
Changed in util-linux (Ubuntu):
importance: Undecided → Medium
no longer affects: linux (Ubuntu)
Changed in util-linux-ng:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.