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 inaccesible. Version-Release number of selected component (if applicable): util-linux-2.13-0.20.1 util-linux-2.13-0.26 from rawhide behaves the same way How reproducible: 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 effect.
The options are better explained in the kernel Documentation/filesystems/udf.txt file: ==== 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 more broken. 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 acceptable. 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 14:19 (1ed4)
> 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, so... ;-)
That helps a bit but I still have a problem. If I manually mount a disk (as root) with mount -t udf /dev/hdb disk -o \ uid=tobias,uid=ignore,gid=tobias,gid=ignore,umask=00000 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 ? Tobias
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 require uid=<username>,uid=ignore 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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?