https://bugzilla.novell.com/show_bug.cgi?id=293433#c12 Bernhard Kaindl <bk@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bk@novell.com AssignedTo|bk@novell.com |dkukawka@novell.com --- Comment #12 from Bernhard Kaindl <bk@novell.com> 2007-08-12 09:35:41 MST --- http://lists.freebsd.org/pipermail/freebsd-gnome/2007-April/017281.html After having studied this thread and having reproduced the same issue with our latest hal-0.5.9_git20070807, I now have a better idea what to do" That report is against current GNOME with HAL and goest as follows: When trying to mount a NTFS volume, I'm getting an error message: "Invalid mount option when attempting to mount the volume '...'." Joe Marcus Clarke, who answers says that gnome-mount sets ntfs/fstype_override=ntfs-3g in gconf:
The default for gnome-mount is to override ntfs with ntfs-3g which our version of HAL does not support. Try setting /system/storage/default_options/ntfs/fstype_override to the empty string, and see if that fixes your problem.
. of which he is right: gnome-mount-0.6/ChangeLog ------------------------------------------------------------------------------- 2007-03-04 David Zeuthen <davidz@redhat.com> Handle NTFS volumes more in a nicer way. This is bgo #394947. * src/gnome-mount.c (volume_mount): Respect new option fstype_override * gnome-mount.schemas.in: Introduce settings for ntfs-3g fs driver and make 'ntfs' redirect to 'ntfs-3g' by default. ------------------------------------------------------------------------------- This override has the effect that whenever gnome-mount is supposed to mount the fstype "ntfs", it remaps this to "ntfs-3g" immediately. A workaround against this overide is to specify the fstype "ntfs" wit the option -f when calling gnome-mount. but when that is not done it has the following effect: HAL, (when the fdi file from ntfs-config is not installed and it has not been restarted since - yes, it really needs a full restart to get to know the new ntfs0-3g options) reports fstype ntfs for the volume, gnome-mount remaps it to ntfs-3g and HAL, having no knowledge of the valid ntfs-3g mount options replys to the legal ntfs-3g mount options with: ** (gnome-mount:14147): WARNING **: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_C81C8DAE1C8D9858 org.freedesktop.Hal.Device.Volume.InvalidMountOption : The option 'force' is not allowed for uid=0 This happens independent of whether ntfs-3g is installed or not. The correct return message should either be the result of the ntfs-3g mount attempt or of ntfs-3g could not be found, the message that ntfs-3g needs to be installed. Without the override, the filesystem is just mounted with the kernel's ntfs module. When the valid ntfs-3g mount options are already specified in the config of hal, and ntfs-3g is not installed, it does not longer reject the mount request not the basis of not allowed mount options but it says: ** (gnome-mount:14406): WARNING **: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_C81C8DAE1C8D9858 org.freedesktop.Hal.Device.Volume.UnknownFilesystemType : Unknown file system 'ntfs-3g' Without the -t (for text only output) flag, a dialog bog opens which says: +-------------------------------------------------------+ | <b>Cannot mount volume</b> | | | | The volume 'FreeAgent Drive' uses the <i>ntfs-3g</i> | | file system which is not supported by your system. | | OK | --------------------------------------------------------+ This is much less misleading as the complaint of not allowed mount options. Therefore, hal's policies have to be extened by a section for ntfs-3g. In theory, it could look similar to the current ntfs section in /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi When, the options are always known ans HAL should give a more helpful answer when ntfs-3g is not installed. Danny was definitely wrong with his comment #3 to this bug:
Reassing to KDE, they have only to use other parameter for the mount call for HAL to mount with fuse (set filesystem for ntfs-3g). No need to change anything here in HAL.
KDE and GNOME can do anything they want, as soon as they need to pass mount options specific for ntfs-3g: * force: GNOME provide a checkbox for this in case the mount withou force fails because the volume is dirty * we need to specify the locale of the user who asks for ntfs-3g to mount a filesystem, or he will either see only paths with only ASCII characters (that's the case when "mount -t ntfs-3g" is called without a non-US-ASCII locale set or garbage from non-ASCII characters if the charsets to not match, or worse, mangled pathnames end up on the disk when files are written. * We do not want to mount with rwxrwxrwx by default ( see bug 293429 ) * The user may want do specify "no_def_options" to make the whole volume completely hidden to all other users (they only get to see the mountpoint's name) or may want to use other permission-related options. For all this, KDE and GNOME are out of luck if HAL does not allow these these mount options, and we should really fix bug 293429, coolo set it to CRITICAL. So I'd say we need the allowed options from my attachment 156942 in comment 11 of this bug in HAL, we can't do anything. Whether HAL should do the remapping of ntfs to ntfs-3g or all the clients of HAL is of course the debatable question. On one hand, the solution in GNOME with gnome-mount's overide_fstype=ntfs-3g has the advantage that the user can individually disable that fstype-default of ntfs-3g, that has to be done for every user who wants to use the kernel's ntfs module by default and there is no way to set a system-level default of not-remapping and have the users which want the remap do it in their setup. When hal does the remapping in a policy file which is defined as %config (noreplace) in the spec file, a system-wide preset can be set there and users which do not want to use the system-wide default provided by hal, can opt out of it in both possible directions, when the hack in gnome-manager to always override the fstype is dropped/ reverted in our gnome-mount. hack is reverted/rejected. So I'm with Dirk Mueller, like he said in his comment #4 to this bug:
the part I don't understand is why HAL doesn't default to the right filesystem type, but instead requests the KDE team to add a custom hack (which is not portable to ivman or gnome or whatever else is out there).
So I am also against having such hacks like the one in gnome-manger currently to ivman, KDE and 'whatever else out there', and I want do drop that hack from gnome. I reassign to Danny because the ball is now in the quarter of HAL again, it *at least* needs to allow the valid ntfs-3g mount options when mounting ntfs-3g, and I propose to add a remapping in %config(noreplace), for which my attachment 156942 of comment #11 would just have to be packaged with HAL with this attribute, there is no other change necessary for that. I'll submit that change to STABLE, but I'm reassigning anyway because with the valid mount option, HAL's storage policy configuration definitely has to be extended in order for ntfs-3g to be usable in an international environment. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.