Bug 293433

That's expected behavior and the default. You can overwrite the defaults in the desktop session and the next mount will use the new seetings. HAL needs to whitelist ntfs-3g if that's acceptable.

Since openSUSE 10.3 will ship with ntfs-3g on all install media by default I recommend to change the default behavior to ntfs-3g. See bug #293420

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.

the fstype is "". So mount_priv needs to be changed to use ntfs-3g when  volume.fstype is "ntfs" - and ntfs-3g is installed. Because it's not installed by default as #2 claims

Bernhard, is it a wise idea to default to ntfs-3g ?

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). 

In my opinion it is not a KDE issue so KDE should not be changed.

I see the following two options:

1. Modify HAL to use ntfs-3g filesystem type by default. This is the more radical way.

2. Leave HAL unchanged but add an .fdi XML file to the ntfs-3g package which tells HAL to use ntfs-3g instead of ntfs. This is the more compatible way but this could be very tricky, if not impossible. I was trying to implement this XML file for weeks with no success. :-(( 

Regards,
Peter.

http://sheldoncode.blogspot.com/2007/08/external-ntfs-3g-automount.html

Thanks Stephan, it works! But HAL behaves very strange on this point so I make this clear for now:

Create the file /usr/share/hal/fdi/policy/10osvendor/10-ntfs-policy.fdi with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
    <device>
        <match key="volume.fstype" string="ntfs">
            <match key="@block.storage_device:storage.hotpluggable" bool="true">
                <merge key="volume.fstype" type="string">ntfs-3g</merge>
                <merge key="volume.policy.mount_filesystem" type="string">ntfs-3g</merge>
                <append key="volume.mount.valid_options" type="strlist">locale=</append>
            </match>
        </match>
    </device>
</deviceinfo>

Reboot, and then plug your external hard disk. Enjoy! 

But this wont work if you create the XML file under /etc/hal/fdi/policy/10osvendor/. Why? Click here 
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/115768 and read the last but one post. It is a HAL bug/feature.

Sometimes HAL ignores the above configuration change and keeps using the old cached config. In that case you should remove the cache file:

# /etc/init.d/haldaemon stop
# rm /var/cache/hald/fdi-cache
# /etc/init.d/haldaemon start

It is still not clear when does HAL update this cache file. Google for this: "fdi-cache invalidation"

instead of removing the cache file you can regenerate it:

/usr/lib/hal/hald-generate-fdi-cache --force

Created attachment 156942 [details]
Updated HAL fdi file for ntfs-3g to allow to set all possibly useful options when using HAL

I tried ntfs-config with our new hal (checked in on Friday evening, it's
based on the current hal git trunk) and the HAL fdi file which ntfs-config
installed (same file as used in that bug) worked flawlessy with it.

URL of ntfs-config:
http://flomertens.free.fr/ntfs-config/download.html

To work for hot-plug, this needs a HAL back end like gnome-volume-manager (which I tested) running and polkitd from PolicyKit also needs to be running.

My my first tries, it rejected my uid (0) from mounting NTFS partitions, but
maybe by system wasn't fully updated to the latest rpms from STABLE yet
or maybe polkitd just needed a restart after the update to latest STABLE.

Policykit is described here:

http://fedoraproject.org/wiki/Releases/FeaturePolicyKit
http://people.freedesktop.org/~david/polkit-spec.html

So PolicyKit can be used to determine which users can mount and if they can mount
without password of if they have to enter the root password when asked for.

So that allows for the access control which is feasible when mounting data
into the system. The traditional UNIX way of doing this was to use an user
group and appropriate permissions, which would allow the same access control, but not as easily configurable and flexible (e.g. users do not have log out and
log in again to have their mount rights changed)

ntfs-config did install that file under this path here (so not under an osvendor director, but that should not play a role, I think):

/etc/hal/fdi/policy/20-ntfs-config-write-policy.fdi

I'm running hald with --daemon=no --verbose=yes in an xterm and see

device_info.c:1036: invalidating fdi cache

each time on stdout of hald when I hit ":w" in vim to update the file.

This verbose stdout also helps to understand how hal works, it's that detailed,
and it tells you what frontends like "gnome-mount" do not tell you (e.g. which
mount option was rejected, or if the fs was already mounted and so on)

With this comment, I'm attaching an updated fdi file which allows to set all possibly useful options when using HAL. locale= shouln't even be needed in
it because it overrides/modifies

I also did set fstype_override in gconf's registry for ntfs ot ntfs-3g.
I found this command should do the same:

gconftool-2 --set --type=string /system/storage/default_options/ntfs/fstype_override ntfs-3g
fstype_override

The Text in the description field is:
>
> The name of the file system driver to use by default when 'ntfs' is detected. > This is useful for configuring the system to use the 'ntfs-3g' driver for all > 'ntfs' file systems by default. User can still choose to use the 'ntfs' file
> system driver by overriding it per-volume or on the command line

At least with this configuration, I simply run 

gnome-mount -t -p 'FreeAgent Drive'

('FreeAgent Drive' is the NTFS-label of an external NTFS disk which I have)

to unmount, add "-u"

as the user who has the privilege "desktop-console" (which I get when I'm
logged in at the system console = by default: sit before the computer)
and my drive is mounted thru hal.

Due to the "-t", I also get textual info back from gnome-mount about what it
just did, and not only the version string.

Because I did ran gconf-editor before that and went in it to /system/storage/default_options/ntfs-3g, and entered the values

locale=en_US.UTF-8
force
dmask=022
fmask=033

It actually mounts with these options, but it does not show me these. I can read them with:

gconftool-2 --get /system/storage/default_options/ntfs-3g/mount_options
[locale=en_US.UTF-8,force,dmask=022,fmask=033]

And I can set per-device and per-filesystem mount settings with:

gnome-mount -p 'FreeAgent Drive' --mount-options no_def_opts,force --mount-point freeagent --write-settings

These mount options replace then the gconf-global ntfs-3g mount options, so it gets only mounted with no_def_opts,force in this example.

BTW: no_def_opts does not cause chown/chgrp/chmod to fail on the volume, but it indeed causes that that the "allow_others" default setting is reset:

l /media/*
ls: cannot access /media/freeagent: Permission denied
d?????????  ? ?    ?       ?             ? freeagent/

So it indeed causes that no information from the mounted volume is visible
to other users.

These per-device/per-volume settings can be retrived with --display-settings and reased with --erase-settings.

These per-volume values are saved in a per-volume-UUID directory+file:

~/.gconf/system/storage/volumes/_org_freedesktop_Hal_devices_volume_uuid_C81C8DAE1C8D9858/%gconf.xml


Seems quite useable, but what we'd still like to know is how we or an admin
could set system-wide default options for mounts.

Maybe it could be done in:

/etc/gconf/gconf.xml.defaults

after a global scheme like the ntfs scheme is created for ntfs-3g:

/etc/gconf/gconf.xml.schemas/system/storage/default_options/ntfs/%gconf.xml

To set default mount options like dmask=022,fmask=033 in the GNOME world would
a part of the solution for bug 293429.

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 [details] 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 [details] 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.

Sorry, but please remove this package from /work/src/done. The patch/fdi-file is complete wrong. 
* You can't overwrite volume.fstype with any other filesystem. It's not allowed to change this key, it contains the information about the type of the real filesystem on the volume, which is a HAL information.
* you can't overwite volume.fstype not only because it's logical incorrect, but also not because you would force all user to use fuse ntfs mounts (a userspace filesystem).
* volume.policy.* properties are complete banned from HAL since ages

Unclear things:
* security aspects of the mount options

Created attachment 158535 [details]
add ntfs-3g to /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi

Ok, thanks, good critique. 

The attached patch for /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi
(which is the file where all allowed mount options are defined for each of the
supported filesystems) adds support for ntfs-3g to hal by defining which mount
options are to be allowed to the users.

This does not cause that NTFS partitions are to be mounted using ntfs-3g,
it only defines which mount options are allowed for ntfs-3g.

Unfortunately, this does not work on its own because tools/hal-storage-mount.c
checks the passed mount options against the mount options which are allowed for the fstype of the disk volume and not the requested fstype for mount.

Without that change, the valid mount options for ntfs-3g work then they are added to the valid mount options for ntfs (found just above the place where
this patch puts in ntfs-3g), which is what Ubuntu has done in early 2007 as
far as I saw from an Ubuntu hal changelog.

Danny, would you have time to discuss that issue in tools/hal-storage-mount.c
and get a fix done?

I appreciate the effort being made to address this bug#293433.  Having typed that, I do believe the severity posted is incorrect.  

NTFS format has been around for years.  USB devices formatted with NTFS have also been around for years. The purchase price is dropping weekly on these devices and many people have them now.  To say the ability to hot plug an external NTFS formatted drive, providing read/write to the external NTFS formatted drive is only an "enhancement" is, I believe, a serious understatement of the user need.  

The user need is hot plugging with BOTH read/write.  Who wants to read an empty drive? No one.  We want to write to external NTFS drives and share them with other OS.  

Reformatting the drive to VFAT32 or a Linux format is often not an option, as such drives are often shared between other computer Operating Systems, with files on the drives greater than 4Gbytes.

I installed Beta2 last night and checked.  The drive mounts well with NTFS read only (NTFS driver) but not NTFS-3G driver.  Hence this "bug" is still present in beta2.  

Good luck in trying to resolve it.

I assume this was fixed in the ntfs-3g package?!

No it's not fixed in ntfs-3g. Raising severity based on customer description
in comment 16. On a personal note, I fully agree whit that comment.

I've packaged ntfs-config for openSUSE 10.3/Factory now with which the users
which have system administration permissions can install an fdi file which
changes the filesystem type of NTFS partitions from ntfs to ntfs-3g, and the
partitions get mounted with it if the corresponding checkbox in ntfs-config is
checked. The approach of renaming the fstype to ntfs-3g might break some NTFS drive icons while it's active but the user get's to be able to configure read-write and read-only access with that.

For this to work, we need to keep the volume.policy rules working in 10.3 and
not remove them. Debian and Ubuntu's NTFS read-write support also depends on
ntfs-config and it has been added to Fedora Extras in early March:
http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repoview/ntfs-config.html

So there will be some resistance to dropping support of these rules from hal
until these communities haven't been able to migrate to an alternate solution.

As I guess that you are also quite busy, I'll assign it to me for testing for now.

Reassigning to me until ntfs-config is in a 10.3 Beta and it's working there.

I will continue to pursue this issue.

*** This bug has been marked as a duplicate of bug 385585 ***