Red Hat Bugzilla – Bug 195860
/bin/mount has a weird notion of "default user" - at least for udf
Last modified: 2008-04-03 17:15:15 EDT
Description of problem:
'man mount' says, in "Mount options for udf", the following:
uid= Set the default user
It is not really clear what that is supposed to mean but one
would expect a behaviour as described for "uid=value and gid=value"
in "Mount options for iso9660" where this is explicit.
Unfortunately (because gnome-mount is stuck of using udf for
some CD) for a value of uid=400 i see only '400 4294967295' in
an ownership of a mount point and all other files and directories
on that CD retain owner and a group of whomever created that CD
on another machine.
In this particular case this has a side-effect of making CD data
Version-Release number of selected component (if applicable):
util-linux-2.13-0.26 from rawhide behaves the same way
Always. It is enough to do a loop mount of a CD image, if udf will
be accepted, to see that uid, and gid, specifications have no real
The options are better explained in the kernel Documentation/filesystems/udf.txt
gid= Set the default group.
uid= Set the default user.
The uid= and gid= options need a bit more explaining. They will accept a
decimal numeric value which will be used as the default ID for that mount.
They will also accept the string "ignore" and "forget". For files on the disk
that are owned by nobody ( -1 ), they will instead look as if they are owned
by the default ID. The ignore option causes the default ID to override all
IDs on the disk, not just -1. The forget option causes all IDs to be written
to disk as -1, so when the media is later remounted, they will appear to be
owned by whatever default ID it is mounted with at that time.
For typical desktop use of removable media, you should set the ID to that
of the interactively logged on user, and also specify both the forget and
ignore options. This way the interactive user will always see the files
on the disk as belonging to him.
So it sounds like mounting with "uid=ignore" may solve the issue, and allow you
to read all files. As far as what Gnome should be using for mount options, I'm
not certain... I think the udf code is behaving as expected, though.
> So it sounds like mounting with "uid=ignore" may solve the issue...
Sigh! There are still no ways to configure options used by gnome-mount
(not mentioning things like making them filesystem specific).
In other words you are really saying "do not use desktop mount tools
to mount CDs as this is broken in many ways". I am afraid that
you are correct and it looks that things are getting here even
OTOH problems still remain. One is that 'mount' manpage is at least
incomplete if one needs to read Documentation/filesystems/udf.txt
to get explanations what manpage may mean and what uid values are
The other problem is that this special behaviour of uid (and gid)
option for udf makes that really unsuitable even for mount via
autofs. There likely be other CDs, with other file systems on those,
and using "uid=ignore" with those will cause errors. If I have
to switch to root to mount such CDs then, of course, I can read
all data anyway.
Clearly "uid=forget" is of no use if this is non-writable medium
written on some system elsewhere.
IMO the kernel is broken insofar mount options with the same name have different
semantics depending on what file system it is. Also, there is no way to even get
a list of what mount options for a file system that a particular instance of the
kernel supports.. and I guess with terrible things like FUSE this is not even
feasible to ask for.. but... that's a rant for another time! :-)
If I understand correctly, would
# mount -t udf -ouid=500,uid=ignore /dev/hdc /mnt/tmp
do the trick? Or is it
# mount -t udf -ouid=500,ignore
I need to know so I can fixup hal / gnome-mount for udf. Thanks
Looks like the former:
[root@magnesium ~]# mount -t udf -o uid=400,ignore /dev/loop0 /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
or too many mounted file systems
[root@magnesium ~]# dmesg | tail -n 1
udf: bad mount option "ignore" or missing value
[root@magnesium ~]# mount -t udf -o uid=400,uid=ignore /dev/loop0
/mnt/testUDF-fs [root@magnesium ~]# dmesg | tail -n 1
INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2006/09/25
> mount -t udf -o uid=400,uid=ignore /dev/loop0
Thanks Eric! At least there is some hope that this can be worked
around but it is a PITA that this rerequires a "special handling"
and a double PITA that 'man mount' is really silent on that.
Hmm just to be clear I meant your former example, not my former example :)
IOW -this- works:
mount -t udf -o uid=400,uid=ignore
I think you had it right but I was re-reading the bug and -I- got confused,
That helps a bit but I still have a problem. If I manually mount a disk (as
mount -t udf /dev/hdb disk -o \
My mount point looks like this
drw-rw-rw- 3 tobias tobias 252 Jan 16 12:07 disk
As you can see I get the proper user/group. But the permissions are all messed
up. It's no use to 'tobias' to have read/write permissions if he can't browse
the root dir.
Is this a defect of how the disk was burned ?
See also http://bugzilla.kernel.org/show_bug.cgi?id=6124
And Andrew just cued up a patch that will hopefully fix this so that it will not
However, I'm not certain about your problem with the permissions on the root dir...
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
I have no way to check that at this moment. Anybody else?