hal rejects to mount ntfs-3g partition

[KevinM]

TEST CASE:
gnome-mount -vnbtd /dev/your_ntfs_partition
fails with "Cannot get volume.fstype.alternative"

NEXT STEP:
Verify fix proposal in https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/300443/comments/4
Fix "debian/20-ntfs-3g-policy.fdi".

--- old description follows ---
Using Jaunty kernel 2.6.27-7 64 bit with latest updates (but not Alpha1).
I'm able to access any ext3 and FAT32 partitions on my PC, but when I try to access NTFS partitions I get an error.
If I go to Places-Computer and select an NTFS drive I get "Cannot mount volume. Unable to mount the volume 'Data Drive'. Details Cannot get volume.fstype.alternative" followed by "Opening "Data Drive"" and then "DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
If I go to Places-Removable Media I get the first and last message but no "Opening "Data Drive".
This error occurs on all three of my NTFS partitions.
My ntfs drive files are as follows:
dpkg -l | grep ntfs
ii libntfs-3g28 1:1.2506-1ubuntu2 ntfs-3g filesystem in userspace (FUSE) libra
ii libntfs-3g31 1:1.2531-1.1ubuntu1 ntfs-3g filesystem in userspace (FUSE) libra
ii ntfs-3g 1:1.2531-1.1ubuntu1 read-write NTFS driver for FUSE

I include my .xsession-errors file as they seems to be problems reported there.

[Linuxfreak78 (linuxfreak78)]

I am receiving the same error. Not sure if I can provide any additional information, but if so please let me know and I will be happy to do so.

[angusyoung (angusmojo)]

You have to install ntfs-config to fix this problem:

# apt-get install ntfs-config

Then go to System/Administration/NTFS Config Tool

and voilà !

[Kjell Braden (afflux)]

Hal seems to reject the partition because the fstype is ntfs and gnome is trying to mount it via ntfs-3g.

The best solution to this would probably be adjusting /usr/share/hal/fdi/policy/10osvendor/20-ntfs-3g-policy.fdi to...
 - append 'ntfs-3g' to volume.fstype.alternative
 - append 'locale=' and 'exec' to volume.mount.ntfs-3g.valid_options

You can test that this works by running:
sudo hal-set-property --udi /your/UDI/to/your/ntfs/device --key volume.fstype.alternative --strlist-post ntfs-3g
sudo hal-set-property --udi /your/UDI/to/your/ntfs/device --key volume.mount.ntfs-3g.valid_options --strlist-post locale=
sudo hal-set-property --udi /your/UDI/to/your/ntfs/device --key volume.mount.ntfs-3g.valid_options --strlist-post exec

Since I'm rather unfamiliar with FDIs I suggest someone else should have a look at this.

[Guy Thouret (guy-thouret)]

I tested the above commands and got the following results:
(After each command was issued I attempted to open the partition by double clicking it's icon in 'Computer' and noted the error message)

UDI of my NTFS partition from hal-device:
/org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4

sudo hal-set-property --udi /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4 --key volume.fstype.alternative --strlist-post ntfs-3g
Cannot get volume.mount.valid_options

sudo hal-set-property --udi /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4 --key volume.mount.ntfs-3g.valid_options --strlist-post locale=
Cannot mount volume.
Invalid mount option when attempting to mount the volume.

sudo hal-set-property --udi /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4 --key volume.mount.ntfs-3g.valid_options --strlist-post exec
This opened an authentication dialog saying something about the security policy didn't allow mounting of local disks.
I entered my password and got the following error:
Unable to mount location
Internal error: No mount object for mounted volume

I then double clicked the disk's icon and it opened as /media/disk as I would expect it to normally operate.

[thegizmoguy (thegizmoguy)]

I can confirm this bug as well in Jaunty x64. However, when I modify the file suggested in comment 4 to:

<?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">volume.fstype.alternative</merge>
        <merge key="volume.policy.mount_filesystem" type="string">volume.fstype.alternative</merge>
        <append key="volume.mount.valid_options" type="strlist">volume.mount.ntfs-3g.valid_options</append>
      </match>
    </match>
  </device>
</deviceinfo>

It has no effect. I didn't have any "exec" option to replace. Can you just post what the updated file should look like because I'm so new with linux i'm probably doing it wrong.

[thegizmoguy (thegizmoguy)]

Installing ntfs-config seemed to have cleared up the problem.

[Guy Thouret (guy-thouret)]

Installing ntfs-config does not clear up the problem.

As far as I am aware ntfs-config is a utility for mounting NTFS partitions, so yes you will be able to mount the partition using ntfs-config as a workaround but this does not offer a fix for the bug.

[Guy Thouret (guy-thouret)]

This is the verbose output I get:
guy@guy-laptop:~$ gnome-mount -vnbtd /dev/sda1
gnome-mount 0.8
** (gnome-mount:14910): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4
** (gnome-mount:14910): DEBUG: read default option 'locale=' from gconf strlist key /system/storage/default_options/ntfs-3g/mount_options
** (gnome-mount:14910): DEBUG: read default option 'exec' from gconf strlist key /system/storage/default_options/ntfs-3g/mount_options
** (gnome-mount:14910): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4 with mount_point='', fstype='ntfs-3g', num_options=2
** (gnome-mount:14910): DEBUG: option='locale=en_GB.UTF-8'
** (gnome-mount:14910): DEBUG: option='exec'
** Message: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4
org.freedesktop.Hal.Device.Volume.UnknownFailure : Cannot get volume.fstype.alternative

[Guy Thouret (guy-thouret)]

After some investigating I found that <match key="@block.storage_device:storage.hotpluggable" bool="true"> was not being matched.

If I removed this match key clause, hal-device lists volume.fstype=ntfs-3g instead of volume.fstype=ntfs and has the keys with the correct mount options.

I can now mount the partition as normal by double clicking it's icon, however I am still asked to authenticate.

I am unsure what effect removing the match key clause will have in other use cases, this could be left as is and volume.fstype.alternative key appended within <match key="volume.fstype" string="ntfs"> but outside of <match key="@block.storage_device:storage.hotpluggable" bool="true">, but that makes no sense to me to look for an ntfs partition and then add ntfs-3g to a list of alternatives if the idea is to use ntfs-3g in the first place.

Note: When I did modify 20-ntfs-3g-policy.fdi to append the volume.fstype.alternative key I got an error about an invalid mount object the first time I tried to mount, but it worked the second.

I have attached my /usr/share/hal/fdi/policy/10osvendor/20-ntfs-3g-policy.fdi

[mahfiaz (mahfiaz)]

I confirm, Guy Thouret's proposed fix works for me too.

[Adomas (adomasj)]

It works for me too! Thank you.

[xorl (xorl)]

Proposed fix also works for me. Tested and confirmed in latest jaunty.

[Noel J. Bergman (noeljb)]

I believe that the issue is that the stock version of 20-ntfs-3g-policy.fdi assumes that the NTFS volumes are hotpluggable, which is why those of us who only use NTFS on such media (e.g., USB/eSATA/firewire external drives) don't see this error, and those of you with local NTFS partitions do.

Attached is a diff from the stock policy to the one that Guy proposes, which seems to be working for you folks. It makes clear that the only change from stock to proposed is the removal of the check for being hot-pluggable storage.

Can anyone justify why the hotpluggable check is important? Else, let's get it removed and push it back upstream.

[Stéphane Maniaci (stephh)]

I can confirm the bug & fix in latest Jaunty.

[Nicolò Dalla Valentina (nicodrummervr)]

ok it's good

[Chris Coulson (chrisccoulson)]

It would be great if somebody experiencing this problem could attach the output of "lshal" to this bug report.

Thanks

[Duncan Lithgow (duncan-lithgow)]

I am still seeing this issue. Here is lshal from my system. It's been running for a while and I've mounted and unmounted the partition manually from the command line.

Here's the relevant part of the file:

udi = '/org/freedesktop/Hal/devices/volume_uuid_2028B48C28B46308'
  block.device = '/dev/sdb1' (string)
  block.is_volume = true (bool)
  block.major = 8 (0x8) (int)
  block.minor = 17 (0x11) (int)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_1ATA_ST9250827AS_5RG1XDLE' (string)
  info.capabilities = {'volume', 'block'} (string list)
  info.category = 'volume' (string)
  info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/storage_serial_1ATA_ST9250827AS_5RG1XDLE' (string)
  info.product = 'Volume H' (string)
  info.udi = '/org/freedesktop/Hal/devices/volume_uuid_2028B48C28B46308' (string)
  linux.hotplug_type = 3 (0x3) (int)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sdb/sdb1' (string)
  org.freedesktop.Hal.Device.Volume.method_argnames = {'mount_point fstype extra_options', 'extra_options', 'extra_options'} (string list)
  org.freedesktop.Hal.Device.Volume.method_execpaths = {'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_names = {'Mount', 'Unmount', 'Eject'} (string list)
  org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'} (string list)
  volume.block_size = 512 (0x200) (int)
  volume.fstype = 'ntfs' (string)
  volume.fsusage = 'filesystem' (string)
  volume.fsversion = '3.1' (string)
  volume.ignore = false (bool)
  volume.is_disc = false (bool)
  volume.is_mounted = false (bool)
  volume.is_mounted_read_only = false (bool)
  volume.is_partition = true (bool)
  volume.label = 'Volume H' (string)
  volume.linux.is_device_mapper = false (bool)
  volume.mount.valid_options = {'ro', 'sync', 'dirsync', 'noatime', 'nodiratime', 'noexec', 'quiet', 'remount', 'exec', 'uid=', 'gid=', 'umask=', 'utf8'} (string list)
  volume.mount_point = '' (string)
  volume.num_blocks = 204796557 (0xc34f28d) (uint64)
  volume.partition.media_size = 250059350016 (0x3a38b2e000) (uint64)
  volume.partition.number = 1 (0x1) (int)
  volume.partition.start = 32256 (0x7e00) (uint64)
  volume.size = 104855837184 (0x1869e51a00) (uint64)
  volume.unmount.valid_options = {'lazy'} (string list)
  volume.uuid = '2028B48C28B46308' (string)

[Chris Coulson (chrisccoulson)]

Thanks, the other relevant device is this one, as this is where the "@block.storage_device:storage.hotpluggable" key is read from:

udi = '/org/freedesktop/Hal/devices/storage_serial_1ATA_ST9250827AS_5RG1XDLE'
  block.device = '/dev/sdb' (string)
  block.is_volume = false (bool)
  block.major = 8 (0x8) (int)
  block.minor = 16 (0x10) (int)
  block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_1ATA_ST9250827AS_5RG1XDLE' (string)
  info.capabilities = {'storage', 'block'} (string list)
  info.category = 'storage' (string)
  info.parent = '/org/freedesktop/Hal/devices/pci_8086_27c4_scsi_host_scsi_device_lun0_0' (string)
  info.product = 'ST9250827AS' (string)
  info.udi = '/org/freedesktop/Hal/devices/storage_serial_1ATA_ST9250827AS_5RG1XDLE' (string)
  info.vendor = 'ATA' (string)
  linux.hotplug_type = 3 (0x3) (int)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sdb' (string)
  storage.automount_enabled_hint = false (bool)
  storage.bus = 'pci' (string)
  storage.drive_type = 'disk' (string)
  storage.firmware_version = '3.AA' (string)
  storage.hotpluggable = false (bool)
  storage.lun = 0 (0x0) (int)
  storage.media_check_enabled = false (bool)
  storage.model = 'ST9250827AS' (string)
  storage.no_partitions_hint = false (bool)
  storage.originating_device = '/org/freedesktop/Hal/devices/computer' (string)
  storage.partitioning_scheme = 'mbr' (string)
  storage.removable = false (bool)
  storage.removable.media_available = true (bool)
  storage.removable.media_size = 250059350016 (0x3a38b2e000) (uint64)
  storage.requires_eject = false (bool)
  storage.serial = '1ATA_ST9250827AS_5RG1XDLE' (string)
  storage.size = 250059350016 (0x3a38b2e000) (uint64)
  storage.vendor = 'ATA' (string)

[Paulo Albuquerque (paulo.albuquerque)]

I installed Jaunty 64 bit Alpha 3 on a test machine and at first all was working as expected. After a recent package update (don't know which one sorry) I started having this problem too.

Do you need any info from me?

[Paulo Albuquerque (paulo.albuquerque)]

I can confirm that the patch proposed by Noel J. Bergman solves the bug.

Thank you!

[Chris Coulson (chrisccoulson)]

Hi,

I was just about to report this to Debian, as the new fdi file comes from them. Can anyone state how this worked on Intrepid? When you tried to mount a volume via Nautilus, was the volume mounted via the old read-only ntfs driver or ntfs-3g?

[Guy Thouret (guy-thouret)]

@Chris Coulson:
Using Intrepid it looks like it is using ntfs-3g also:

guy@guy-laptop:~$ sudo gnome-mount -vnbtd /dev/sda1
[sudo] password for guy:
gnome-mount 0.8
Xlib: extension "RANDR" missing on display ":0.0".
** (gnome-mount:14645): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4
** (gnome-mount:14645): DEBUG: read default option 'locale=' from gconf strlist key /system/storage/default_options/ntfs-3g/mount_options
** (gnome-mount:14645): DEBUG: read default option 'exec' from gconf strlist key /system/storage/default_options/ntfs-3g/mount_options
** (gnome-mount:14645): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4 with mount_point='', fstype='ntfs-3g', num_options=2
** (gnome-mount:14645): DEBUG: option='locale=en_GB.UTF-8'
** (gnome-mount:14645): DEBUG: option='exec'
Mounted /dev/sda1 at "/media/disk"

[xorl (xorl)]

You can fix that simply by opening gedit finding ntfs3g defualts and
removing the locale line.

On Wed, Jan 21, 2009 at 3:37 PM, Guy Thouret <email address hidden> wrote:

> @Chris Coulson:
> Using Intrepid it looks like it is using ntfs-3g also:
>
> guy@guy-laptop:~$ sudo gnome-mount -vnbtd /dev/sda1
> [sudo] password for guy:
> gnome-mount 0.8
> Xlib: extension "RANDR" missing on display ":0.0".
> ** (gnome-mount:14645): DEBUG: Mounting
> /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4
> ** (gnome-mount:14645): DEBUG: read default option 'locale=' from gconf
> strlist key /system/storage/default_options/ntfs-3g/mount_options
> ** (gnome-mount:14645): DEBUG: read default option 'exec' from gconf
> strlist key /system/storage/default_options/ntfs-3g/mount_options
> ** (gnome-mount:14645): DEBUG: Mounting
> /org/freedesktop/Hal/devices/volume_uuid_D0C4C81DC4C807A4 with
> mount_point='', fstype='ntfs-3g', num_options=2
> ** (gnome-mount:14645): DEBUG: option='locale=en_GB.UTF-8'
> ** (gnome-mount:14645): DEBUG: option='exec'
> Mounted /dev/sda1 at "/media/disk"
>
> --
> hal rejects to mount ntfs-3g partition
> https://bugs.launchpad.net/bugs/300443
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Chris Coulson (chrisccoulson)]

I can confirm that it works on Intrepid too with the ntfs-3g driver. I'm trying to understand why it really doesn't work on Jaunty now though. The new fdi file wasn't shipped in Intrepid, so all NTFS volumes had "volume.fstype=ntfs", in the same way that internal drives now have in Jaunty. So for internal volumes, nothing changed in Jaunty and the new fdi file that Debian introduced should have no effect here. However, mounting worked ok in Intrepid.

So I'm wondering if something changed in HAL. I'd like to understand what the real problem is here rather than taking a stab in the dark.

[Chris Coulson (chrisccoulson)]

Right, I think I understand why this is broken now. In Intrepid, gnome-mount is configured by default to mount any partitions with "volume.fstype=ntfs" with the ntfs-3g driver. In Jaunty this is the same, but it doesn't work because it appears that the alternative fstype needs to be specified in "volumes.fstype.alternative" when you are mounting a filesystem with a driver that is not the same as what is specified in volumes.fstype. This constraint doesn't appear to exist on Intrepid

So, this would have broken anyway with or without the ntfs-3g change from Debian.

[Chris Coulson (chrisccoulson)]

I think the cleanest fix for this is to modify the HAL fdi to unconditionally set volume.fstype to ntfs-3g for all NTFS volumes when ntfs-3g is installed, and also set volume.fstype.alternatives to ntfs for those, as this will allow people to still use gnome-mount to mount NTFS volumes with the old ntfs driver, should they choose too. This should make the behaviour similar to Intrepid.

[Chris Coulson (chrisccoulson)]

I've packaged the new upstream version of ntfs-3g and put it in to my PPA for you to try out, which has a fix for this bug. Hopefully, this new version will end up in Jaunty sometime soon, once we've figured out how to handle the change in version numbering scheme (see bug 320031).

You will need to edit gconf key /system/storage/default_options/ntfs-3g/mount_options and remove the "exec" flag. The ntfs-3g driver doesn't support it (and doesn't seem to have supported it before either), and mounting will fail now if it is specified. I noticed this when creating the new HAL fdi file, and that is a bug in gnome-mount which needs fixing separately.

Feedback would be most appreciated

[Chris Coulson (chrisccoulson)]

Actually, scrap the PPA idea. I deleted the package from it, as we've decided how to handle the new version numbers

[Nicolò Dalla Valentina (nicodrummervr)]

ok thanks if you have need also contact hello hello thanks to me of all

[Launchpad Janitor (janitor)]

This bug was fixed in the package ntfs-3g - 1:2009.1.1-0ubuntu1

---------------
ntfs-3g (1:2009.1.1-0ubuntu1) jaunty; urgency=low

  * New upstream version (LP: #320031):
    - Built-in, transparent UTF-8 conversion support.
    - The 'locale=' mount option is not used anymore for filename
      characterset conversion. Filenames are always converted to UTF-8.
    - Support for unlimited file ane directory creation.
  * Updated files due to SO version bump:
    - debian/control, debian/rules, libntfs-3g48.docs,
      libntfs-3g48.install, libntfs-3g48-udeb.install,
      libntfs-3g-dev.links, ntfs-3g.links
  * debian/25-ntfs-3g-policy.fdi:
   - Renamed, as policies now have to be applied after
     20-storage-methods.fdi.
    - Updated for objects where "volume.fstype=ntfs":
      - Make ntfs-3g the default driver and make the old ntfs
        driver an alternative.
      - This is because HAL will no longer mount a volume with a
        filesystem driver that is different to what is specified in
        "volume.fstype", unless it is explicitly defined in
        "volume.fstype.alternatives". By default, gnome-mount
        attempts to mount ntfs volumes with the ntfs-3g driver.
        This change makes this work properly again, and makes
        it possible for users to choose the old ntfs driver too.
        (fixes LP: #300443)
  * debian/changes/Changelog:
    - Updated to document new upstream changes.

 -- Chris Coulson <email address hidden> Thu, 22 Jan 2009 20:31:21 +0000

[Jorge Gustavo (jgr)]

Changing /usr/share/hal/fdi/policy/10osvendor/20-ntfs-3g-policy.fdi with the sugested changes solved my problem (with the permanent NTFS partitions).

Thanks!

[Nicolò Dalla Valentina (nicodrummervr)]

ok thanks for all bye bye

[Chris Coulson (chrisccoulson)]

Jorge - No need to adjust as above, as this is fixed in Jaunty now (2009.1.1-0ubuntu1)

[Laurence (l-d-anderson)]

Still an issue on Jaunty beta netbook remix until ntfs-config installed

[Chris Coulson (chrisccoulson)]

Laurence - You would be better off opening a new bug report with some useful information rather than commenting on a well-understood bug that was fixed a long time ago.

[jedioetzi (jedioetzi)]

is my problem related to this issue?
 gnome-mount -vnbtd /dev/sda1
gnome-mount 0.8
** (gnome-mount:27881): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_00F2CD3CF2CD36A6
** (gnome-mount:27881): DEBUG: read default option 'locale=' from gconf strlist key /system/storage/default_options/ntfs-3g/mount_options
** (gnome-mount:27881): DEBUG: read default option 'exec' from gconf strlist key /system/storage/default_options/ntfs-3g/mount_options
** (gnome-mount:27881): DEBUG: Mounting /org/freedesktop/Hal/devices/volume_uuid_00F2CD3CF2CD36A6 with mount_point='', fstype='ntfs-3g', num_options=2
** (gnome-mount:27881): DEBUG: option='locale=LC_CTYPE=en_US.UTF-8;LC_NUMERIC=it_IT.UTF-8;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=it_IT.UTF-8;LC_ADDRESS=it_IT.UTF-8;LC_TELEPHONE=it_IT.UTF-8;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=it_IT.UTF-8'
** (gnome-mount:27881): DEBUG: option='exec'
** Message: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_00F2CD3CF2CD36A6
org.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.mount-fixed auth_admin_keep_always <-- (action, result)

[Chris Coulson (chrisccoulson)]

No. You don't have permission to mount the volume.

[jedioetzi (jedioetzi)]

correct if I execute `sudo gnome-mount -vnbtd /dev/sda1` it works.
But if I use nautilus for mount the device I get:
Opening "46,0 GB Media".
and after a while:
Unable to mount location
DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

I 'm pretty sure that with 8.04 I was asked for a password for to mount that volume and the mount was successful, since 8.10 it fails without asking password

[wirespot (wirespot)]

Upgrade from 8.10 to 9.04 produced this bug for me. Package 'ntfs-config' was already installed. I had to do `apt-get remove ntfs-config; apt-get install ntfs-config` and `dpkg-reconfigure ntfs-config` before the bug went away.

[dino99 (9d9)]

hi,

here is my story:
- i use a fat32 usb stick to install new distro with unetbootin. That stick formated with intrepid gparted work like a charm on intrepid & jaunty 32.
- today i want to install an other os, so i reformat this stick with jaunty gparted (0.4.3-0ubuntu1) and i get an error when ive tried to mount it: "cannot get volume.fstype.alternative"
This error is widely described here and over forums as a ntfs-3g one.

What i have done next, is to reformat this stick with format xp sp3 (always fat 32). rebooting with jaunty 32, i'm surprised when i see this stick mounted, no more error !!!

So, now i'm not sure that ntfs-3g is responsible, thinking instead about gparted (0.4.3-0ubuntu1)

[Pazkooda (pazkooda)]

ntfs-3g version: 1:2009.2.1-0ubuntu2

Here is my story :)

I receive "cannot get volume.fstype.alternative" while mounting NTFS partition via Nautilus on fresh install of UNR (all updates installed). But it is installed next to original Windows installation. Partition were prepared using "Partiton editor" from Live CD (gparted). All resizing and new partiton preparation for UNR were done by me manually.

So I think that dion99 may be right and issue is solved only partially.
I've attached lshal output. Please let me know if I can give you any additional info that may help solving my case.

[L.D. Paniak (ldpaniak)]

I'm seeing the same error on the XFCE desktop of Karmic/ Mythbuntu Alpha 6.

I am using a Windows-formatted NTFS USB stick (8GB). On insertion, I get the "cannot get volume.fstype.alternative" popup on the desktop.

The stick can be mounted manually by root and used for r/w operations without trouble.

lshal output is attached.