Bug 466948
Summary: | Unable to mount and auto-mount ntfs volumes after today's update | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Shaopu Chiu <yikechiu> | ||||
Component: | hal | Assignee: | Richard Hughes <richard> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | alexl, allenhalsey, davidz, mclasen, opossum1er, pertusus, posguy99, reggiani.mattia, rhughes, richard, tbzatek, tcallawa | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-10-30 12:48:41 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 438943 | ||||||
Attachments: |
|
Description
Shaopu Chiu
2008-10-14 17:42:13 UTC
Hmm, that doesn't seem right. If you manually mount the partition in a terminal, does it give an error? I'm not sure what to do. I remember I typed "mount /dev/sda4" in terminal last night, the termianl give me an error message says "unable to find /dev/sda4/ in /etc/mtab and something. I dare not change anything in those two files because I'm noob on linux. What should I do? I'll do what I can and report when I'm home. Problem still remains in today's update... Same situation: Invalid mount option. Okay, so: 1. Look in your /etc/fstab, and see if there is an entry for /dev/sda4. 2. Try mounting it manually from a terminal: mount -t ntfs /dev/sda4 /mnt/point (where /mnt/point is wherever you want that partition) Please capture the log of you running the command along with any errors it throws. I cannot reproduce any sort of ntfs mount failure on my end, so I'm going to need your help in describing in detail what you're doing to cause this. I see no /dev/sda3 or /dev/sda4 in my /etc/fstab but I can mount my sda3 or sda4 with the terminal. And I can see them in /mnt too. So this problem is not because of ntfs-3g.Thanks. But they should be auto-mounted after the xsession is on, and should be seen in the "computer:///". The ntfs drivers was in "computer:///" but they were un-mounted. After I mounted them with the terminal and they disappeared from "computer:///". I don't know what went wrong, maybe gvfs?Last time I saw the Dbus problem was because of the gvfs. By the way,I saw a person from Malta has exactly the same problem on fedora forum. So I'm not the only one who has this problem. Thanks any way. So, here's a quick lesson on automounting filesystems. The config file that controls which filesystems get mounted automatically is /etc/fstab. Now, I suppose it is possible that something else is automounting this partition that is hooked into dbus, but I'm not aware of it. Add a line to your /etc/fstab for your ntfs partitions that looks something like this: /dev/sda3 /mnt/point1 ntfs defaults 0 0 (one line for each partition) Then, when your system boots up, it will automount these entries (the initscripts call mount -a). In addition, because they're in /etc/fstab, you'll be able to mount them manually by simply running: mount /mnt/point1 (or mount /dev/sda3). I'm going to reassign this bug to dbus, hopefully the maintainer will have a better idea of what is actually happening here. Thanks a lot. I tried some usb disks. Nothing wrong with flash memory disks. But ntfs hard disks won't mount automatically. > But they should be auto-mounted after the xsession is on, and should be seen in
> the "computer:///".
What makes you think they should be automounted ?
Please try harder to describe the situation exactly enough to understand what the configuration of your system is, what you are trying to do, and what you expect to happen.
Tentatively moving it to gvfs, thats at least better than dbus.
I'm sorry about my English...I'll try to describe harder. ^_^ Because they were automounted before so I expect them to be automounted. I have at least three partitions on my hard drive. Two of them are NTFS systems. Before that update, I can always see the two NTFS volumes mounted in Nautilus(click on Places>Computer), and when I plug usb hard drives(NTFS system) in, it was always auto-mounted (plug and play). After that update caused troubles, I click on Places> Computer and see those two volumes unmounted. I tried to click on the volumes' icon to mount it, it shows error messages which says "Cannot mount volume. Invalid mount option when attempting to mount the volume 'Disk1'." and "Unable to mount Disk1 ,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." System settings? I didn't change many of them. I use gnome desktop. On my desktop I run Screenlets, Fusion-icon, Cairo-dock, and an IM called Ibus. I closed them to try to mount the volumes but to no avail. And I forgot to say, my fedora 10 was upgraded from 9 through yum. I am experiencing this too. My Fedora 10 was regular install, not upgrade from 9. Prior to updating my system on 2008-10-15, my ntfs usb disk would auto-mount (icon showed up on desktop and in Places> Computer), just like my vfat thumb drive still does. I can manually mount it using: # mkdir /mnt/Maxtor160 # mount -t ntfs /dev/sdb1 /mnt/Maxtor160/ but this doesn't make it appear on the desktop or in Places> Computer. I tried booting into previous kernel (2.6.27-3.fc10.i686), but that didn't help. Discussion at FedoraForum.org: http://forums.fedoraforum.org/showthread.php?t=201690 hi boys , I have the same problem with the same error but i think the problem is only with NTFS volume and "automount" because is possible to "manual-mount" the volume with no error . I noticed that my 2008-10-14 updates included hal-0.5.12-3. I reverted to hal-0.5.12-2 and the problem went away. Steps Taken: Found hal package at koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=74 [me]$ wget http://koji.fedoraproject.org/packages/hal/0.5.12/2.20081001git.fc10/i386/hal-0.5.12-2.20081001git.fc10.i386.rpm [me]$ wget http://koji.fedoraproject.org/packages/hal/0.5.12/2.20081001git.fc10/i386/hal-libs-0.5.12-2.20081001git.fc10.i386.rpm [root]# rpm -Uvh --force hal-libs-0.5.12-2.20081001git.fc10.i386.rpm hal-0.5.12-2.20081001git.fc10.i386.rpm Added rhughes to cc list. This thread sounds relevant: http://lists.freedesktop.org/archives/hal/2008-October/012368.html "The next HAL release will break at least all Ubuntu and Fedora based distros about 12 million users) not being able to automount NTFS." Yep, adding the fdi file used by archlinux [1] and slackware [2] fixed the problem. Can we have this added to our hal-info package? [1] http://wiki.archlinux.org/index.php/HAL#NTFS [2] http://lists.freedesktop.org/archives/hal/2008-October/012367.html (In reply to comment #13) > I noticed that my 2008-10-14 updates included hal-0.5.12-3. I reverted to > hal-0.5.12-2 and the problem went away. > > Steps Taken: > > Found hal package at koji: > http://koji.fedoraproject.org/koji/packageinfo?packageID=74 > > [me]$ wget > http://koji.fedoraproject.org/packages/hal/0.5.12/2.20081001git.fc10/i386/hal-0.5.12-2.20081001git.fc10.i386.rpm > [me]$ wget > http://koji.fedoraproject.org/packages/hal/0.5.12/2.20081001git.fc10/i386/hal-libs-0.5.12-2.20081001git.fc10.i386.rpm > [root]# rpm -Uvh --force hal-libs-0.5.12-2.20081001git.fc10.i386.rpm > hal-0.5.12-2.20081001git.fc10.i386.rpm > > Added rhughes to cc list. This tip is ok , i have installed the two packets , and now "gnome-mount" mount NTFS partitions . I can confirm that the .fdi file resolves the automount failure for removable devices with NTFS partitions. I'll add it to ntfs-3g (but not a dependency on hal). Alternately, this could go into hal-info, but I have no problem putting it in ntfs-3g. ntfs-3g-1.5012-2.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/ntfs-3g-1.5012-2.fc8 ntfs-3g-1.5012-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/ntfs-3g-1.5012-2.fc9 Please install these updates (or, if you're in rawhide, yum update ntfs-3g) and report back a comment to the update as to whether it resolves the issue for you. This will help get it out of updates testing much faster. hi boys , I have tested the packet ntfs-3g-1.5012-2.fc9 on Fedora 10 Beta with kernel 2.6.27.2-23.rc1.fc10.i686 and two differents packets of hal and hal-libs , this is the result : TEST 1 (WORK OK) : # rpm -q ntfs-3g ntfs-3g-1.5012-2.fc9.i386 # rpm -q hal hal-0.5.12-2.20081001git.fc10.i386 # rpm -q hal-libs hal-libs-0.5.12-2.20081001git.fc10.i386 TEST 2 (DON'T WORK) : # rpm -q ntfs-3g ntfs-3g-1.5012-2.fc9.i386 # rpm -q hal hal-0.5.12-3.20081013git.fc10.i386 # rpm -q hal-libs hal-libs-0.5.12-3.20081013git.fc10.i386 Sorry for my english . (In reply to comment #21) > hi boys , > I have tested the packet ntfs-3g-1.5012-2.fc9 on Fedora 10 Beta That's odd. Why didn't you use the ntfs-3g in the F10 repository? You should be able to run "yum update ntfs-3g" and get the f10 build. Also, please tell me how you are testing this. (In reply to comment #22) > That's odd. Why didn't you use the ntfs-3g in the F10 repository? You should be > able to run "yum update ntfs-3g" and get the f10 build. > > Also, please tell me how you are testing this. If i run "yum update ntfs-3g" , i not found ntfs-3g for F10. Sorry tom ,i have devasted the laptop , now i have cleaned the packets on my laptop , this is the result : DON'T WORK # rpm -q ntfs-3g ntfs-3g-1.5012-1.fc10.i386 #rpm -q hal hal-0.5.12-3.20081013git.fc10.i386 #rpm -q hal-libs hal-libs-0.5.12-3.20081013git.fc10.i386 WORK rpm -Uvh --force hal-0.5.12-2.20081001git.fc10.i386.rpm hal-libs-0.5.12-2.20081001git.fc10.i386.rpm # rpm -q ntfs-3g ntfs-3g-1.5012-1.fc10.i386 # rpm -q hal hal-0.5.12-2.20081001git.fc10.i386 # rpm -q hal-libs hal-libs-0.5.12-2.20081001git.fc10.i386 (In reply to comment #24) > Sorry tom ,i have devasted the laptop , now i have cleaned the packets on my > laptop , this is the result : How are you testing this? I have a USB key with an NTFS partition and it works correctly with hal-0.5.12-3.20081013git.fc10 and ntfs-3g-1.5012-2.fc10. I have tested with internal hdd of my laptop fomated with NTFS , this night I test with external hdd with ntfs partition and tell you the result . I've just built hal-0.5.12-7.20081022git.fc10 for rawhide if that helps. I have updates packages at this version : ntfs-3g-1.5012-2.fc10.i386 hal-0.5.12-7.20081022git.fc10.i386 (thanks Richard for info) hal-libs-0.5.12-7.20081022git.fc10.i386 The situations is : External hdd (usb) with NTFS partitions WORK FINE Internal hdd (sata) with NTFS DON'T WORK , command "gnome-mount -d" or click on device return error " Unable to mount volume , mount option not valid" . Okay... so the difference between 0.5.12-2 and 0.5.12-3 is a newer hal code drop and two patches. I'm guessing this is why: +commit a0d82b80f775faf666aa699f354338098286ff20 +Author: Danny Kukawka <danny.kukawka> +Date: Thu Oct 9 13:54:26 2008 +0200 + + Revert "allow 'locale=' NTFS mount option for Linux" + + This reverts commit a372bf79e16a5c6c00d0e262745dc935de364ca2. + + The ntfs-3g or ntfs-fuse package has to install their own fdi + file to allow locale as mount option if needed. Otherwise HAL + would allow invalid mount options for plain kernel ntfs. + + fdi/policy/10osvendor/20-storage-methods.fdi | 1 - + 1 files changed, 0 insertions(+), 1 deletions(-) Specifically, what it does is remove this line: <append key="volume.mount.valid_options" type="strlist">locale=</append> from this section: <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name" string="Linux"> The ntfs-3g .fdi only covers: <match key="@block.storage_device:storage.hotpluggable" bool="true"> ...which isn't going to match an internal drive. So... what I need is help from someone who understands .fdi format to fix the ntfs-3g included .fdi file to cover both cases... I will attach my current version to this bug. Created attachment 321207 [details]
ntfs-3g custom .fdi (needs fixes to support both internal and external automounting)
ntfs-3g-1.5012-2.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ntfs-3g'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-9039 ntfs-3g-1.5012-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ntfs-3g'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9041 (In reply to comment #28) > I have updates packages at this version : > > ntfs-3g-1.5012-2.fc10.i386 > hal-0.5.12-7.20081022git.fc10.i386 (thanks Richard for info) > hal-libs-0.5.12-7.20081022git.fc10.i386 > > The situations is : > > External hdd (usb) with NTFS partitions WORK FINE > > Internal hdd (sata) with NTFS DON'T WORK , command "gnome-mount -d" or click > on device return error " Unable to mount volume , mount option not valid" . Reggiani, please download this package: http://koji.fedoraproject.org/packages/ntfs-3g/1.5012/3.fc10/i386/ntfs-3g-1.5012-3.fc10.i386.rpm Then, upgrade and retest! I think this should fix everything. Hi Tom , I have tested the package in this configuration : hal-0.5.12-8.20081027git.fc10.i386 hal-libs-0.5.12-8.20081027git.fc10.i386 ntfs-3g-1.5012-2.fc10.i386 All disk with NTFS partitions (Internal and External USB) work Very good work boys !!! ntfs-3g-1.5012-3.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/ntfs-3g-1.5012-3.fc8 ntfs-3g-1.5012-3.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/ntfs-3g-1.5012-3.fc9 ntfs-3g-1.5012-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. ntfs-3g-1.5012-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. (In reply to comment #34) > Hi Tom , > > I have tested the package in this configuration : > > hal-0.5.12-8.20081027git.fc10.i386 > hal-libs-0.5.12-8.20081027git.fc10.i386 > ntfs-3g-1.5012-2.fc10.i386 > > All disk with NTFS partitions (Internal and External USB) work > > Very good work boys !!! Since I had to fix one more bug, I want to make sure I didn't introduce a regression... Reggiani, can you upgrade to: http://koji.fedoraproject.org/packages/ntfs-3g/1.5012/4.fc10/i386/ntfs-3g-1.5012-4.fc10.i386.rpm And retest to confirm that everything still works okay... thanks! Hi Tom , I have installed (updated) your package and all work fine ( internale and external hdd ) , this is the packages installed on my system : hal-0.5.12-9.20081027git.fc10.i386 hal-libs-0.5.12-9.20081027git.fc10.i386 ntfs-3g-1.5012-4.fc10.i386 I confirm that everything works OK Good Work ! |