Description of problem: After applying updates as of March 31, RAWHIDE mounts my USB pen drive with wrong permissions (it belongs to root). The problem is that it varies as updates come and go: sometimes it works fine, sometimes it doesn't even mount the drive as a normal user (root can mount manually) and sometimes it mounts the drive but the owner is root and thus a normal user can't write to it. It's a bit exciting to see which behavior are you going to get next time you reboot after doing a yum update. This report is based on a system with Fedora 7 Test 3 (plus updates). The original installation was done with Test 2 Live CD and updated to RAWHIDE March 31. Note that I am not completely sure if this bug report belongs to hal. So please, point out the right package after analysis. Version-Release number of selected component (if applicable): hal-0.5.9-0.git20070326.fc7 hal-gnome-0.5.9-0.git20070326.fc7 kernel-2.6.20-1.3036.fc7 gnome-volume-manager-2.17.0-4.fc7 How reproducible: Always Steps to Reproduce: 1. Insert a USB flash memory. 2. Try to create a new file or delete an existing one with nautilus. 3. Or you could try copying a file from your hard drive to the USB drive. Actual results: A normal user can't create, delete or copy files to the flash drive (root can). Expected results: That I can actually create or delete files in my flash drive. Additional info: I got this in /var/log/messages after plugging in my USB drive: Mar 31 13:16:54 localhost kernel: usb 1-3: new full speed USB device using ohci_hcd and address 3 Mar 31 13:16:54 localhost kernel: usb 1-3: configuration #1 chosen from 1 choice Mar 31 13:16:54 localhost kernel: scsi3 : SCSI emulation for USB Mass Storage devices Mar 31 13:16:59 localhost kernel: scsi 3:0:0:0: Direct-Access JetFlash TS1GJF2B 2.00 PQ: 0 ANSI: 2 Mar 31 13:17:00 localhost kernel: ready Mar 31 13:17:00 localhost kernel: SCSI device sdb: 2045184 512-byte hdwr sectors (1047 MB) Mar 31 13:17:00 localhost kernel: sdb: Write Protect is off Mar 31 13:17:00 localhost kernel: sdb: assuming drive cache: write through Mar 31 13:17:00 localhost kernel: SCSI device sdb: 2045184 512-byte hdwr sectors (1047 MB) Mar 31 13:17:00 localhost kernel: sdb: Write Protect is off Mar 31 13:17:00 localhost kernel: sdb: assuming drive cache: write through Mar 31 13:17:00 localhost kernel: sdb: sdb1 Mar 31 13:17:00 localhost kernel: sd 3:0:0:0: Attached scsi removable disk sdb Mar 31 13:17:00 localhost kernel: sd 3:0:0:0: Attached scsi generic sg2 type 0 Mar 31 13:17:04 localhost hald: mounted /dev/sdb1 on behalf of uid 500 I hope this helps to solve the problem, but what I want is to get this bug fixed in a definitive manner. I don't understand why it keeps coming once in a while with every update. I know this is RAWHIDE but I am really afraid that updates after Fedora 7 Final Release are going to show the same behavior.
BTW, I can right click the device on my desktop and unmount it. So it's weird I can do that but I can't write to it. Cheers.
I totally confirm this for F7Test3. I did a F3Test3 installation from scratch and have this problems now, too. But I didn't have this problems with F7Test3.
I think the gconf schemas are not installed correctly; I just ran into this myself and when debugging it I noticed that /system/storage/default_options/<fs>/* were missing. Reinstalling the gnome-mount RPM by hand seemed to fix it. Can you verify this? Adding Jeremy, Ray and Matthias since I think all of them did some changes related to gconf for test3. Thoughts?
Yes, I can verify this. I did rpm -e --nopes gnome-mount yum install gnome-mount and then I get again write access as user when I insert an USB stick. Thanks.
mispelled... rpm -e --nodeps gnome-mount yum install gnome-mount
I can confirm the suggested fix is working for me. Now the USB drive is mounted as [user]:root so I can write to it. The funny thing is that this doesn't happen with Test 3 Live CD... may be a broken update after release? Is it safe to close this bug now?
*** Bug 230956 has been marked as a duplicate of this bug. ***
*** Bug 232631 has been marked as a duplicate of this bug. ***
*** Bug 235041 has been marked as a duplicate of this bug. ***
Please see comment 3 for a temporary fix. I'm unsure of the root cause still but I suspect a bug in %post in gnome-mount.
Odd, the GConf handling in gnome-mount.spec looks ok (apart from the fact that it is missing a %pre scriptlet. Ray, any ideas ?
*** Bug 235708 has been marked as a duplicate of this bug. ***
Could this be a problem when updating the package gnome-mount? working scenario; 1. sudo rpm -ev --nodeps gnome-mount -> /system/storage/default_options/<fs>/* : still there 2. sudo rpm -ivh gnome-mount-0.5-3.fc7.i386.rpm (from Test3) -> /system/storage/default_options/<fs>/* : still there: mount ok. 3. sudo yum update gnome-mount -> /system/storage/default_options/<fs>/* : MISSING: mount NOK. /etc/gconf/gconf.xml.defaults/%gconf-tree.xml contains: <dir name="storage"> <dir name="default_options"> <dir name="ntfs"> </dir> <dir name="udf"> </dir> <dir name="iso9660"> </dir> <dir name="vfat"> </dir> </dir> </dir> 4. sudo rpm -ev --nodeps gnome-mount (step 1.) 5. sudo yum install gnome-mount -> /system/storage/default_options/<fs>/* : there again: mount ok. regards, Steven.
Ah, so it likely _is_ the missing %pre scriptlet
I hope this is fixed in 0.6-2.fc7.
Nope... Still occurring.
(In reply to comment #16) > Nope... Still occurring. Seems to be fixed in gnome-mount-0.6-2.fc7. Thank you!
(In reply to comment #17) > (In reply to comment #16) > > Nope... Still occurring. > > Seems to be fixed in gnome-mount-0.6-2.fc7. > Thank you! Sorry, spoke too soon. Still not working.
"Still not working" is a bit too vague. What is the symptom you are seeing ? I would not be surprised if upgrading to 0.6-2 does not fix things, since that still runs the broken %preun script of 0.6-1. What needs verification is that a) installing 0.6-2 does give you gconf entries b) upgrading from 0.6-2 to a newer version does not remove the gconf entries
(In reply to comment #19) > "Still not working" is a bit too vague. What is the symptom you are seeing ? > I would not be surprised if upgrading to 0.6-2 does not fix things, since that > still runs the broken %preun script of 0.6-1. > What needs verification is that Ok, sorry. I'm fully knowledgeable into the packaging process. When upgrading from 0.6-1 to 0.6-2, the %preun of 0.6-1 is run? Seems logical indeed. 1. I build myself a 0.6-3 from the 0.6-2 SRPM. Upgrading to that package keeps the gconf entries in place. 2. removing (nodeps) removes the entries. 3. installing 0.6-2 puts them back in place. So it seems it is fixed.
(In reply to comment #20) > Ok, sorry. I'm fully knowledgeable into the packaging process. This is missing a _NOT_.
Thanks for doing all that work. I'm going to assume this is fixed then.
Hi there, I experience the same problem with 0.6-2.fc7 I connected my Nokia mobile phone in storage mode to the pc, it was recognized and mounted as /media/SD with the corresponding icon on the Desktop and I could read all data but not write on any folder. After removing gnome-mount and installing it again I was now able to write on all folders except the root folder of the device. Here is /proc/mounts after reinstalling gnome-mount /dev/sdf /media/SD vfat rw,nosuid,nodev,uid=500,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii 0 0 before I'm pretty sure that uid=500 was missing.
(In reply to comment #23) > Hi there, I experience the same problem with 0.6-2.fc7 > After removing gnome-mount and installing it again I was now able to write on > all folders except the root folder of the device. If you updated from 0.6-1.fc7, then it's actually supposed to go wrong, since the error is located in a missing %preun of this package. When updating from the current rawhide (0.6-2.fc7) to the future version this issue should be fixed, as 0.6-2 has a correct %preun. As shown in Comment #20. regards, Steven
I see, then I didn't understand correctly. Thank you for the answer but I will keep this in mind when a newer version is released to check if it is indeed fixed. Regards, George
David, maybe we should do another gnome-mount update to help people over the bad %preun ?
T(In reply to comment #26) > David, maybe we should do another gnome-mount update to help people over the bad > %preun ? This would of course only help people that upgrade from current rawhide. It wouldn't change anything for clean test3 upgraders. If you leave the rpm as-is and only bump the revision, of course. Putting a hack into the current package to counter the missing %preun of the previous probably isn't desirable. I don't know what the ratio is between these groups of people. Maybe it _is_ worth it.
*** Bug 237585 has been marked as a duplicate of this bug. ***
*** Bug 238005 has been marked as a duplicate of this bug. ***
I have found another problem which causes this 'not writable' problem and is also very very very important. If I manually, through the nautilus drive properties, set as an extra mount option 'utf8', which I need in my external drives, then the partition is *not* mounted as writable by the user. Check the /proc/mounts is two cases: Without utf8 writable but I can't see correctly some filenames: /dev/sdf1 /media/Memorybird vfat rw,nosuid,nodev,uid=500,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii 0 0 With utf8 , *not* writable but can see the filenames: /dev/sdf1 /media/Memorybird vfat rw,nosuid,nodev,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,utf8 0 0 As you can see in the first case the option uid=500 is added which makes it writable but in the second case is not!!! Also in the second case iocharset remains while there is not point since utf8 is defined. This is very important bug because it renders the gnome-mount mechanism useless for international users like myself.
(In reply to comment #30) > If I manually, through the nautilus drive properties, set as an extra mount > option 'utf8', which I need in my external drives, then the partition is *not* > mounted as writable by the user. It's not "extra options", it's replacing the default options. So just add the option 'uid=500' (or whatever) in addition to utf8 and things should start working again. (Yes, I'll be the first to say that the gnome-mount nautilus extension is extraordinarily crappy and bad UI; I know because I wrote it. But at least it gets the job done.. Anyway, hopefully we'll have something better for Fedora 8. Thanks.) David
David, Please add, before releasing FC7, a note in the drive and volume tab of nautilus properties that mount options should be separated with a space character and not with a comma!!! Small addition but believe me very very very useful for people who are used to separate mount option with a comma, like myself :) Cheers
(In reply to comment #32) > David, > > Please add, before releasing FC7, a note in the drive and volume tab of nautilus > properties that mount options should be separated with a space character and not > with a comma!!! Small addition but believe me very very very useful for people > who are used to separate mount option with a comma, like myself :) Not going to happen; a) we're in feature freeze; b) the string wouldn't be translated. Sorry.
*** Bug 238246 has been marked as a duplicate of this bug. ***
*** Bug 238754 has been marked as a duplicate of this bug. ***