unable to fix bad mounting options without editing gconf manually

Bug #231218 reported by Loren
48
This bug affects 5 people
Affects Status Importance Assigned to Milestone
gnome-mount
Won't Fix
Medium
gnome-mount (Ubuntu)
Invalid
Low
Unassigned
Declined for Intrepid by Sebastien Bacher
Declined for Jaunty by Sebastien Bacher

Bug Description

Binary package hint: gnome-mount

OS AND PACKAGE VERSION:

loren@loren-desktop:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04
loren@loren-desktop:~$ apt-cache policy gnome-mount
gnome-mount:
  Installed: 0.8~svn20080225-0ubuntu4
  Candidate: 0.8~svn20080225-0ubuntu4
  Version table:
 *** 0.8~svn20080225-0ubuntu4 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

DESCRIPTION:

If the user enters invalid Mount Options that prevents a device from automounting, there is no way for the user to correct the error without extensive knowledge of how the automount system works.

HOW TO REPRODUCE:

1) After logging in, Attach a removable storage device to the system (via USP for example)

2) After the device mounts, locate the devices icon on the desktop.

3) Right click on the icon, Select "Properties", and go to the "Drive" tab, and open the "Settings" disclosure triangle

4) Enter an illegal "Mounting Option" (for instance "-r" instead of "ro")

5) close the dialog

6) disconnect the device... wait for the system to recognize the device is unplugged and remove the devices icon

7) reconnect the device

RESULT:

The user is present a dialog box indicating "Cannot mount volume: Invalid mount option when attempting to mount the volume 'USB DRIVE'" with only an OK button for user interaction. There is no way for the user to correct the invalid entry before or after the user presses ok.

WORK AROUND:

After much unsuccessful googling, I was finally able to eventually able to remedy this issue by:

1) interrogating ps to determine what program owned the "Cannot mount volume" dialog (identifying it as gnome-mount)

2) reading the gnome-mount man page to determine where gnome-mount stores its mount options ( /system/storage/drives/DEVICE_SPECIFICATION/mount_options within the gconf system)

3) using gconf-editor to edit the mount option to be the correct value "ro".

This does not strike me as anything an average user would consider the least bit obvious.

SUGGESTED BEHAVIOR:

I think the most obvious way to handle this is to make any device that fails to be mounted leave a mostly-disabled icon on the desktop as long as it's connected (probably with an indicator that it's disabled due to an error, such as the exclamation icon overlay that MicroSoft uses in their hardware manager*), so that the user can easily modify the devices properties and correct the error.

NOTES:

* This suggested icon idea relies on the desktop manager (nautilus?) supporting some system for icon overlays that I don't believe it currently does. Even without this gnome-mount could still display a disabled icon.

Revision history for this message
George Ganoe (george-ganoe) wrote :
Download full text (3.8 KiB)

I would like to add my support to this report. I had similar problems. Here is my supporting report:

Hotplug of msdos formatted Compact Flash has unexpected results after changing the "File System:" under Media Properties Volume tab Setting to msdos.

By default, the Compact Flash device is mounted as a vfat volume, and has the uid option set to my UID thus giving me full access to the device which is expected. However, when I set the "File System:" value to msdos, then unmount, and replug the Compact Flash, it accepts the msdos file system type, but is now mounted without the uid option and hence becomes owned by root. Although as a user I have read access to it, I can't make any changes without using sudo or launching a root terminal. When I try to set a mount option of "uid=1000 gid=1000", I get an error "Cannot mount volume. Invalid mount option when attempting to mount the volume." and have no apparent way to recover from this error. The documentation doesn't help as there is no guidance about this dialog box tab.

After spending several hours exploring various man pages, Ubuntu Forums, and a lot of trial and error, I found a clue to turn on the "Applications"/"System Tools" menu, and found the "Configuration Editor". Still with no clear guidance, I found the "system"/"storage"/"volumes" tab which contained a string with my devices UUID. Once there, I was able to figure out how to unset the invalid "mount_options" key and get the device to automount again, but still with no write access.

While I was in the configuration editors system/storage tab, I noticed that under default options one option that is set for vfat is "uid=". When I try to set a mount option of "uid=" in the "Mount Options:" field of the Media Properties dialog boxes volume tab, I get an error "Cannot mount volume. Unable to mount the volume." and again am locked out and have to go back the the Configuration Editor to recover. While there, instead of unsetting the "mount_options" key, I decided to try actually setting it to my UID, and finally was able to get the device to mount as I wanted it to.

It seems to me that any options entered into the settings for the Drive and Volume tabs should be validated before being accepted by the application, especially if the consequence of the entry will result in a need to use functionality that is hidden from the user by default. In my case, my original purpose was to be able to use my Linux system to more easily make changes to data and configuration files on a compact flash disk that contains a MSDOS Partition for a legacy MSDOS system that I need to maintain. I have noticed in the past that if vfat entries get written to the MSDOS disk, I get spurious errors and unpredictable operation from the legacy system, thus the need to have the compact flash disk mounted as an MSDOS partition. My normal procedure has been to use

   mount -t msdos /dev/DEVICE -o uid=MYUID,gid=MYGID MOUNT_POINT

as root, and everything worked as I wanted it to. As Linux has "progressed" I have noticed that the compact flash would automount, but as a vfat volume, so I would need to unmount it then go to root and mount it as before. After...

Read more...

Revision history for this message
Loren (loren-silvercash) wrote :

This appears to be related to Bug #107668 also. Make sure that relevant fixes work for that bug also.

Changed in gnome-mount:
status: New → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

that's an upstream issue and should be sent to bugzilla.gnome.org

Changed in gnome-mount:
importance: Undecided → Low
Revision history for this message
Ricardo Pérez López (ricardo) wrote :

I come from duplicate bug #382114, and I have the same issue in my fully-updated Jaunty.

Steps to reproduce:

Binary package hint: gnome-mount

Steps to reproduce:

1. Go to Places->Computer.
2. Right-click on any volume and select Properties (the volume must be previously mounted).
3. Click on Drive or Volume tabs.
4. Click on Settings to show the mount options.
5. Enter any wrong information in the "Mount point", "Filesystem" or "Mount options" fields. Try, for instance, entering "foo" (without the quotes) in "Mount options" field and enter "good" or reasonable values in the other two fields.
6. Unmount the volume and try to mount it again.

Result: An error dialog appears indicating that the volume couldn't be mounted (as expected, because you entered wrong mounting options on step #5). However, you can't fix the wrong options because you can't access to the Drive and Volume tabs until the volume has been mounted, and you can't mount the volume because the mount options are wrong. There's no way to fix the bad options entered on step #5.

The bug is fully reproducible and could lead to have an inaccessible volume without an easy way to repair the access to the volume.

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Bugreport submitted to upstream.

Changed in gnome-mount:
status: Unknown → New
Changed in gnome-mount (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Loren (loren-silvercash) wrote :

Looks like this is now in the Gnome bugzilla db here: https://bugzilla.gnome.org/show_bug.cgi?id=584351

Changed in gnome-mount:
importance: Unknown → Medium
Changed in gnome-mount:
status: New → Won't Fix
Revision history for this message
Phillip Susi (psusi) wrote :

This package has been removed from Ubuntu. Closing all related bugs.

Changed in gnome-mount (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.